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ABSTRACT 


Critical  to  the  success  of  all  future  battlefield  commanders  is  the  rapid  retrieval  of 
relevant,  time  sensitive  information.  Some  of  this  information  will  be  available  locally 
while  the  remainder  is  stored  in  the  United  States.  DARPA’s  Battlefield  Awareness  and 
Data  Dissemination  ^ADD)  program  attempts  to  deliver  heterogeneous  data  to  the 
battlefield  using  Asynchronous  Transfer  Mode  (ATM)  protocol.  ATM  was  originally 
designed  to  implement  dynamic  virtual  channels  over  duplex,  high-speed,  high  capacity 
fiber  optic  cabling.  The  problem  addressed  was  to  determine  which  algorithm  best 
schedules  calls  on  BADD’s  ATM  network  that  uses  static  virtual  channels  over  dmpIpY, 
error  prone,  long  delay,  satellite  links.  Because  the  BADD  project  uses  ATM  in  such  an 
vmusual  way,  and  because  of  the  need  to  determine  a  schedule  for  transmissions  over  the 
heterogeneous  static  channels,  we  modeled  BADD  using  the  state-of-the-art  network 
simulation  tool.  Optimized  Network  Engineering  Tools  (OPNET).  We  determined 
several  modifications  that  must  be  made  to  existing  network  simulators  to  allow  them  to 
model  next-generation  networks.  Our  simulation  shows  that  a  greedy  algorithm  yields  a 
53%  decrease  in  the  overall  completion  time  and  a  46%  increase  in  average  bit  throughput 
over  FIFO  scheduling. 
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INTRODUCTION 


A.  BACKGROUND 

From  several  years  before  Operation  Urgent  Fury,  the  invasion  in  Grenada  in 
1983,  until  after  Operation  Just  Cause,  the  invasion  in  Panama  in  1989,  the  Depart¬ 
ment  of  Defense  (DoD)  fielded  numerous  new  stand-alone  automated  systems.  These 
systems  provided  solutions  to  narrowly  focused  problems  and  were  not  interoperable 
with  other  DoD  systems.  The  story  of  the  enterprising  young  Army  oflScer  in  Grenada, 
calling  his  home  base  in  North  Carolina  to  coordinate  naval  gunfire  support,  because 
his  equipment  could  not  directly  communicate  with  naval  equipment,  illustrates  the 
problems  encoimtered  by  DoD  personnel  in  using  such  systems.  Today  these  systems 
are  referred  to  as  “vertical”  because  they  do  not  facilitate  “horizontal”  communica¬ 
tion.  (They  are  also  sometimes  referred  to  as  “stove-pipe.”)  From  multiple  experiences 
such  as  the  one  described  in  Grenada,  the  DoD  has  learned  that  this  vertical  design 
paradigm  leads  to  massive  duplication  of  subcomponents  and  incompatibility  between 
systems.  Such  a  paradigm  also  interferes  with,  rather  than  facilitates,  joint  military 
operations.  In  light  of  the  current  downsizing  in  military  force  structures,  coupled  with 
the  dwindling  military  research  and  development  funds,  the  DoD  must  develop  and 
field  systems  that  are  integrated  both  vertically  and  horizontally.  All  new  automated 
systems  must  share  their  information  across  a  wide  spectrum  of  military  applications 
that  support  interoperability  requirements.  These  modified  design  environments  are 
also  essential  for  the  required  reduction  in  procurement  costs. 

The  Department  of  Defense  has  made  some  progress  in  recent  years  towards 
adapting  and  embracing  civilian  research,  development,  and  procurement  practices. 
It  now  seeks  to  learn,  adopt  or  adapt,  as  necessary,  these  corporate  practices  to  meet 
unique  military  requirements,  such  as  providing  highly  mobile  communications  and 
automated  support  in  sparse  communication  environments.  For  example,  utilizing  a 
commercial  mobile  phone  system  as  the  baseline  for  development  of  a  mobile  military 
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communication  platform  makes  sense;  however,  the  military  must  often  add  redund¬ 
ancy  to  its  networks.  This  redundancy  is  needed  to  permit  communication  to  continue 
even  when  some  communication  lines  are  lost  in  battle.  Other  examples  of  consider¬ 
ations  that  military  planners  must  address,  but  their  commercial  counterparts  need 
not,  include  noisy  Radio  Frequency  (RF)  links,  extreme  bandwidth  constraints,  and 
security  concerns. 

Recent  and  ongoing  developments  in  the  area  of  information  availability  and 
accessibility  within  large,  widely  distributed,  commercial  corporations  have  direct 
applications  within  military  applications.  With  high  mobility  and  global-reach  re¬ 
quirements,  the  military  must  develop  and  field  automated  systems  that  integrate  all 
available  and  accessible  information.  The  exploration  and  possible  use  of  emerging 
technologies,  such  as  Asynchronous  Transfer  Mode  (ATM)  [Ref.  1],  for  high¬ 
speed  data  communications  are  essential  to  the  success  of  future  military  systems. 

In  one  such  effort,  personnel  at  the  Naval  Command  Control  and  Ocean  Sur¬ 
veillance  Center,  Research,  Development,  Training,  and  Evaluation  Division  (NRaD), 
under  the  direction  of  Dr.  Clifford  J.  Warner,  are  examining  the  use  of  ATM  to  sat¬ 
isfy  the  requirements  for  the  transmission  of  multimedia  data  over  the  Navy’s  .Joint 
Maritime  Communication  System  [Ref.  2].  They  are  focusing  on  three  areas; 

•  Actively  participating  in  the  Internet  Engineering  Task  Force’s  efforts  to  stand¬ 
ardize  an  approach  to  reliable  multicast. 

•  Integrating  Internet  Protocol  (IP)  Quality  of  Service  (QoS)  guarantees  with 
ATM  QoS  to  ensure  QoS  support  through  multiple  layers  of  the  network,  in¬ 
cluding  the  subnetwork  level. 

•  Actively  testing  ATM  equipment  in  their  labs  to  identify  the  ability  of  ATM 
switches  to: 

1.  support  multimedia  applications, 

2.  support  IP  and  ATM  QoS  guarantees, 

3.  interoperate  with  different  ATM  switches, 

4.  support  efficient  multicast  protocols,  and 
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5.  integrate  with  legacy  systems. 


These  extensive  efforts  demonstrate  a  recognition  by  the  military  science  and 
technology  experts  that  ATM  is  a  technology  that  might  be  exploitable  in  future 
Command  and  Control,  Communication,  Computer  and  Intelligence  (C4I)  systems. 
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Figure  1.  BADD  Overview  (From  [Ref.  3]). 


Figure  1  displays  the  Battlefield  Awareness  and  Data  Dissemination 
(BADD)  System  [Ref.  3].  The  BADD  system  is  an  ATM-based  communication 
system  that  has  the  primary  goal  of  integrating  all  available  information  to  digit¬ 
ize  the  battlefield  and  to  ensure  that  the  local  battlefield  commander  maintains 
information  dominance  over  opposing  forces.  The  information  needed  to  digitize  the 
battlefield  may  be  available  either  within  the  local  operating  forces  environment  or  may 
be  stored  in  the  vast  electronic  libraries  maintained  by  diverse  organizations  within 
the  continental  United  States.  These  electronic  libraries  include  the  Defense  Intelli- 
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gence  Agency  (DIA),  the  Defense  Mapping  Agency  (DMA),  and  Cable  Network  News 
(CNN).  The  BADD  program,  under  the  direction  of  the  Defense  Advanced  Re¬ 
search  and  Project  Agency  (DARPA),  attempts  to  integrate  voice,  data,  video, 
and  imagery  in  this  single  system. 

Fundamental  to  the  success  of  the  BADD  program  is  the  rapid  access  and 
transfer  of  information  to  and  from  the  battlefield.  This  transfer  of  information  must 
include  high-speed  network  connectivity  over  vast  distances.  Likewise,  the  program 
must  include  plans  for  scheduling  retransmission  of  data  that  is  lost  due  to  network 
failures,  which  are  likely  in  the  military  environment.  Additionally,  the  military  does 
not  want  to  lose  any  important  data.  This  requires  the  rescheduling  of  lower  priority 
data  when  it  is  preempted  by  higher  priority  data. 

This  thesis  investigates,  through  simulation,  several  problems  resulting  from 
scaling  of  the  BADD  project  from  its  current  prototype  size  to  its  eventually  en¬ 
visioned  use.  In  particular,  we  use  Optimized  Network  Engineering  Tools 
(OPNET),  a  commercial  software  product  from  MILS,  to  simulate  BADD  both  in  its 
current  implementation  and  in  planned  future  implementations  [Ref.  4].  Our  major 
work  concentrates  in  the  areas  of  scheduling  algorithms  for  ATM  virtual  channels  on 
the  BADD  satellite  network  link. 

B.  MOTIVATION 

The  motivation  for  our  research  stems  from  the  need  to  ensure  that  the  Amer¬ 
ican  forces  and  our  allies  remain  the  most  informed  forces  on  the  battlefield.  To 
accomplish  this  goal,  the  warfighter  must  immediately  obtain  all  of  the  most  current, 
relevant  data.  As  the  battlefield  becomes  digitized,  the  amount  of  operational,  in¬ 
telligence,  and  logistical  information  that  may  be  of  interest  to  the  commanders  is 
overloading  the  capacities  of  the  existing  networks.  BADD  examines  new  solutions 
that  will’ permit  the  timely  distribution  of  relevant  information  to  even  the  lowest 
echelons. 
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Broadcast  is  an  efficient  means  of  getting  information  out  to  a  wide  audience. 
Broadcast  information  has  been  proven  successful  for  the  military  with  the  Navy’s  Tac¬ 
tical  Receive  Applications  Network  and  the  Air  Force’s  Tactical  Information  Broadcast 
System  Network.  Most  recently,  the  Bosnia  Command  and  Control  Augment¬ 
ation  (BC2A)  Initiative,  supporting  forces  in  the  former  Yugoslavia,  has  proven 
the  usefulness  of  broadcasting  heterogeneous  sets  of  data.  However,  broadcasting  all 
information  to  everyone  will  no  longer  be  an  option  because  there  is  simply  too  much 
information.  Instead,  we  need  to  ensure  that  each  of  the  warfighters  has  the  informa¬ 
tion  that  is  most  relevant  to  them  and  that  the  information  is  as  current  as  possible. 
To  meet  this  need  requires  the  use  of  a  mufiicast  protocol.  The  BADD  program  plans 
to  use  the  Global  Broadcast  Service  (GBS),  multiple  static  virtual  ATM  chan¬ 
nels,  and  smart  filtering  to  implement  multicast  of  heterogeneous  data  to  satisfy  the 
demands  of  the  forward  deployed  warfighter.  One  problem  that  the  BADD  designers 
have  not  yet  tackled  is  that  of  scheduling  the  data  to  be  broadcast  over  the  multiple 
static  virtual  ATM  channels  in  such  a  way  so  as  to  maximize  the  probability  of  the 
high  priority  data  reaching  the  warfighter.  The  research  for  this  thesis  concentrates  in 
that  area,  borrowing  algorithms  from  SmartNet  [Ref.  5],  a  framework  for  scheduling 
computation  in  a  high  performance,  heterogeneous  computing  network. 

C.  METHODOLOGY 

We  first  construct  an  OPNET  simulation  for  the  BADD  network  using  its 
current  configuration  as  a  baseline  model  for  further  analysis.  Then,  we  will  run  sim¬ 
ulations  using  two  different  scheduling  algorithms  for  scheduling  data  to  be  broadcast 
over  the  static  virtual  ATM  channels.  (The  BADD  architecture  will  hardwire  these 
channels  into  the  satellite  uplink  switch.)  The  first  baseline  simulation  will  run  with 
First-In,  First  Out  (FIFO)  scheduling.  The  second  simulation  will  incorporate  intelli¬ 
gent  scheduling  with  algorithms  used  in  SmartNet,  a  United  States  Navy  developed 
scheduler.  We  will  then  run  multiple  simulations  to  measure  the  maximum  throughput 
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of  the  network  with  the  different  schedulers.  Finally,  we  will  perform  analysis  on  our 
results  in  order  to  determine  the  utility  of  intelligent  schedulers  for  these  networks. 


D.  ORGANIZATION 

The  thesis  is  divided  into  seven  chapters.  Chapter  II  reviews  communication 
fundamentals  including  TCP/IP  and  ATM  protocols.  Chapter  III  provides  an  over¬ 
view  of  the  BADD  program  and  the  general  architecture  of  the  network.  Chapter  IV 
elaborates  on  SmartNet’s  Intelligent  Scheduling  and  the  past  successes  of  these  al¬ 
gorithms.  Chapters  V  and  VI  provide  background  information  on  the  simulation  soft¬ 
ware  we  are  using  and  elaborates  on  the  design  of  our  simulation.  Chapter  VII  presents 
the  results  of  our  simulation,  provides  the  analysis  of  our  simulation,  makes  recom¬ 
mendations  for  future  work,  and  presents  our  conclusions.  The  appendices  provide 
explanations  of  technical  terms,  computer  code,  scripts  of  simulations,  and  a  list  of 
acronyms  used  throughout  this  document. 
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II.  COMMUNICATION  FUNDAMENTALS 


A.  OVERVIEW 

This  chapter  reviews  some  computer  network  basics.  In  particular,  it  con¬ 
centrates  on  basic  computer  communication,  basic  data  characteristics,  basic  Trans¬ 
mission  Control  Protocol(TCP),  User  Datagram  Protocol(UDP),  and  Asyn¬ 
chronous  Transfer  Mode(ATM)  services.  If  the  reader  is  already  familiar  with 
computer  networks,  he  or  she  can  skip  this  chapter. 

B.  BASIC  COMPUTER  COMMUNICATION 

Basic  computer  commimication  consists  of  three  distinct  components:  a  source 
(or  sender),  a  destination  (or  receiver),  and  a  path  (or  communication  network) 
between  the  source  and  destination.  Based  on  the  complexity  of  the  computer  commu¬ 
nication,  either  the  source,  destination,  or  the  communication  network  can  add  header 
information  to  ensure  reliability  in  the  communication.  The  International  Standards 
Organization  (ISO)  developed  its  Open  Systems  Interconnection  (OSI)  model  for  com¬ 
puter  communication  (see  Table  I)  to  isolate  various  functionalities  within  different 
layers.  By  grouping  the  communication  functions  into  layers,  communication  services 
at  a  particular  layer  need  only  focus  on'  the  needs  of  that  specific  layer,  using  the  ser¬ 
vices  of  the  underlying  layers.  They  need  not  be  concerned  with  the  implementation 
of  the  layers  below. 

C.  DATA  CHARACTERISTICS 

The  three  basic  parameters  that  describe  most  communication  services  are 
time  transparency,  bit  rate,  and  connection  mode  [Ref.  1].  In  the  following 
subsections  we  will  elaborate  on  each  of  these  parameters. 
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Layer  7  Provides  access  to  users  and  provides  distributed 
Applications  information  services. 


Layer  6  Provides  independence  to  applications  using  different 
Presentation  data  representations. 

Layer  5  Provides  control  structures  for  communication  between 
Session  different  cooperating  applications. 

Provides  reliable  transfer  of  data  between  endpoints; 
provides  end-to-end  error  recovery  and  flow  control. 
Provides  upper  layers  with  independence  from  data 
transmission;  responsible  for  managing  communication 
connections. 

Layer  2  Provides  reliable  transfer  of  information  across 
Data  Link  the  physical  link;  responsible  for  synchronization, 
error  control  and  flow  control. 


Table  1.  Open  Systems  Interconnection  (OSI)  Model  for  Computer  Communications 
(Modified  From  [Ref.  6]). 

1.  Time  Transparency 

Time  transparency  refers  to  the  relationship,  in  time,  between  occurrences 
of  events  at  both  the  source  and  the  destination.  Time  transparency  is  formally 
defined  as  the  near  absence  of  time  delay  and  time  jitter  [Ref.  1].  Time  delay 
is  the  difference  between  the'  time  the  sender  transmits  the  information  and  the  time 
the  information  arrives  at  the  receiver.  Time  jitter  occurs  when  different  parts  of  a 
transmission  arrive  at  the  receiver  with  different  time  delays.  Network  delay  and  jitter 
are  primarily  the  result  of  two  factors:  propagation  delay  and  processing  delay. 

Propagation  delay  is  the  physical  delay  of  the  medium;  that  is,  the  distance 
(d)  that  the  signal  must  travel  from  the  source  to  the  destination,  divided  by  the 
transmission  speed  of  the  physical  medium.  The  transmission  speed  is  bounded  by 
the  speed  of  light  in  a  vacuum  and  (y)  in  fiber  optic  cable  where,  c  is  the  speed  of 
light  in  meters  per  second.  For  example,  the  propagation  delay  in  a  one  kilometer 


Layer  1 
Physical 


Transfers  bits  over  a  physical  medium  at  the  level 
of  electrical  signals. 


Layer  4 
Transport 
Layer  3 
Network 


fiber  optic  cable  is  given  as 


O.OOOOlsecond. 
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Processing  delay  is  the  sum  of  the  times  required  for  the  network  hardware  and  network 
software  to  process  the  message  at  each  node  within  the  network. 

Some  communication  services  demand  that  the  time  required  to  complete  a 
transmission  be  bounded.  One  example  of  a  such  a  requirement  is  that  time  delay  in 
voice  data  transmission  must  not  exceed  25ms.  When  voice  data  time  delays  exceed 
this  threshold,  the  receiver  will  notice  “choppiness”  in  the  conversation.  Services  that 
require  a  low  bound  on  time  delay  are  called  real-time  services. 

2.  Bit  rate 

There  are  four  basic  classes  of  bit  rate  services;  constant  bit  rate,  variable  bit 
rate,  available  bit  rate,  and  unspecified  bit  rate  [Ref.  7]. 

•  Constant  bit  rate  is  analogous  to  the  bottles  on  a  conveyor  belt  in  a  bottling 
plant.  The  bottles  move  through  the  process  at  a  constant  rate.  Constant 
bit  rate  communication  service  places  bits  on  the  transmission  media  at  a 
constant  rate  and  takes  them  off  the  media  at  the  same  rate.  Again,  using  the 
transmission  of  voice  data  as  an  example,  the  bit  rate  is  constant  at  64kbps 
for  digital  pulse  code  modulated  (PCM)  voice  data.  The  input  voice  signal  is 
sampled  8000  times  per  second  and  each  sample  is  represented  by  8  bits;  each 
8-bit  sample  is  produced  at  this  rate  to  give  a  constant  64kbps  bit  rate. 

•  Variable  bit  rate  is  analogous  to  train  cars  traveling  on  a  railway.  All  cars  are 
on  the  same  track  traveling  at  the  same  speed,  however,  the  train  caxs  have 
different  sizes.  Some  cars  are  large  size  carrying  two  levels  of  automobiles,  some 
are  medium  size  carrying  products  in  a  box  car,  and  some  are  small  size  like 
empty  flatcars.  If  we  view  a  railway  tunnel  as  the  size  of  a  communications  link, 
we  can  see  that  at  times  the  tunnel’s  area  is  filled  when  large  cars  come  through 
and  is  almost  empty  when  flatcars  come  through.  Video-teleconferencing  is 
an  example  of  a  variable  bit  rate  service.  Using  current  video  compression 
schemes,  a  base  frame  is  sent,  followed  by  a  series  of  smaller  frames  containing 
the  differences  between  the  current  frame  and  the  base  frame  [Ref.  7]. 

•  .Available  bit  rate  services  is  the  service  primarily  used  to  support  the  World 
Wide  Web.  Due  to  financial  constraints,  companies  cannot  afford  to  install 
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communication  services  that  will  support  their  peak  communication  require¬ 
ments.  They  instead  decide  upon  some  minimum  communication  capacity  that 
must  be  obtained  and  then  live  with  delays  when  peak  data  loads  are  applied. 
Because  the  communication  service  cannot  support  sustained  peak  load,  this 
service  must  support  congestion  control  to  prevent  network  congestion  that 
might  lead  to  network  failure. 

•  Unspecified  bit  rate  has  no  congestion  control  and  does  nothing  to  ensure 
delivery.  With  this  service,  data  is  placed  onto  the  network  and,  with  luck, 
arrives  at  the  destination.  If  congestion  occurs  within  the  network,  data  may 
be  randomly  discarded  without  notifying  the  user.  File  transfer  and  email  are 
possible  users  of  this  type  of  service  because  applications  have  no  constraints 
on  time  of  delivery  and  they  maintain  their  own,  higher  order,  error  control 
mechanisms. 

3.  Connection  mode 

A  particular  service  may  be  connection-oriented  or  connectionless  [Ref. 
7].  In  a  connection-oriented  service,  a  complete  connection  from  sender  to  receiver 
is  established  before  transmitting  any  data.  An  example  of  this  type  of  service  is 
the  original  telephone  circuit  switching  system.  Under  the  telephone  system,  a  user 
picks  up  the  phone  and  dials  a  telephone  number.  The  telephone  system  establishes 
a  dedicated  circuit  between  the  two  users.  This  circuit  is  only  used  by  these  two 
customers  until  one  customer  hangs  up  the  telephone,  thereby  releasing  the  connection. 
One  might  visualize  this  service  as  a  tube,  where  one  user  at  a  time  pours  information 
in  at  one  end  and  the  other  user  takes  the  information  out.  The  information  will 
always  arrive  in  the  same  order  in  which  it  was  sent. 

The  other  common  connection  mode  is  called  connectionless  [Ref.  7].  With  this 
service,  the  user  assigns  a  destination  address  to  each  message  and  places  the  message 
into  the  network.  The  user  has  no  input  and  no  knowledge  about  the  route  the  message 
will  take  to  its  destination  address.  Furthermore,  the  user  has  no  guarantee  that  two 
messages  sent  by  the  same  user  to  the  same  destination  will  arrive  at  that  destination 
in  the  same  order  in  which  they  are  sent.  An  example  of  a  connectionless  service  is 
the  postal  system. 
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D.  COMMUNICATION  SERVICES  AND  PROTOCOLS 

Now  that  we  have  defined  basic  computer  communications  and  data  character¬ 
istics,  we  begin  to  describe  some  common  communication  architectures  which  are  used 
within  the  BADD  system.  As  will  be  depicted  in  Chapter  III,  BADD  is  an  integrated 
system  of  diverse  communication  services;  this  section  will  discuss  each  service  with 
a  focus  on  ATM. 

1.  TCP  Data  IVansport  Protocol 

TCP  resides  at  the  transport  layer  (layer  4  in  the  OSI  model),  and  is  designed 
to  work  on  top  of  an  unreliable  network  [Ref.  7].  This  connection-oriented  protocol 
improves  the  reliability  of  communication  by  adding  sequencing,  acknowledgments, 
flow  control,  and  congestion  control  mechanisms.  Due  to  its  complexity,  TCP  often 
becomes  a  major  bottleneck  in  high-speed  communications. 

Figure  2  depicts  the  packet  format  for  a  TCP  packet.  The  standard  data  field 
for  a  TCP  packet  is  1500  bytes  long,  with  a  maximum  length  of  64  kbits. 

The  fields  within  the  TCP  packet  are  as  follows: 

•  Source  Port.  This  is  the  sender’s  port  for  its  application. 

•  Destination  Port.  This  is  the  receiver’s  port  for  its  application. 

•  Sequence  Number.  This  field  contains  the  sequence  number  of  the  first  data 
byte  in  this  TCP  segment. 

•  Acknowledgment  Number.  Used  for  acknowledgment  messages,  this  fields 
specifies  the  sequence  number  of  the  next  data  byte  TCP  expects  to  receive. 

•  TCP  HL.  TCP  HL  stands  for  TCP  Header  Length  and  specifies  the  total 
number  of  bytes  contained  in  the  header. 

•  URG  Flag.  A  bit  that,  when  set,  tells  the  protocol  to  use  the  value  in  the 
Urgent  Pointer. 

•  ACK  Flag.  A  bit  that,  when  set,  alerts  the  protocol  that  the  acknowledgment 
number  is  valid. 

•  PSH  Flag.  This  bit,  when  set,  activates  the  Push  Function.  The  Push  func¬ 
tion  pushes  this  packet  up  to  the  application  layer  even  if  the  buffer  is  not  yet 
full. 
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Figure  2.  TCP  Packet  Format  (From  [Ref.  7]). 


•  RST  Flag.  This  bit  is  set  when  either  side  detects  problems  with  the  connec¬ 
tion  and  the  connection  must  be  reset. 

•  SYN  Flag.  A  bit  marking  this  packet  as  a  request  to  establish  a  connection. 

•  FIN  Flag.  This  bit  is  set  when  either  the  sender  or  receiver  finishes  with  a 
connection. 

•  Window  Size.  Used  by  the  sliding  window  flow  control  mechanism. 

•  Checksum.  An  error  detection  code  for  the  header  and  data. 

•  Urgent  Pointer.  A  pointer  to  the  byte  that  immediately  follows  the  urgent 
data. 

2.  UDP  Data  Transport  Protocol 

UDP.  in  contrast  to  TCP,  provides  a  connectionless  service  for  application  level 
procedures  [Ref.  7].  It  also  differs  from  TCP  in  its  complexity  and  support  for  reliable 
communications.  UDP  is  considered  unreliable  because  it  provides  no  mechanisms  for 
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acknowledging  receipt  of  data  and  no  protection  against  duplicate  receptions.  UDP  is 
often  used  when  speed  is  more  important  and  end-to-end  reliability  mechanisms  are 
incorporated  in  the  layer  that  sits  above  the  UDP  layer.  Figure  3  depicts  the  packet 
format  for  the  UDP  packet.  Like  the  TCP  header,  the  maximum  packet  size  for  UDP 
packets  is  approximately  64  kbits. 


Figure  3.  UDP  Packet  Format  (From  [Ref.  7]). 


Each  of  the  fields  within  the  UDP  packet  are  explained  below. 

•  Source  Port.  This  is  the  local  port  for  the  application,  at  the  sender,  using 
the  UDP  transport  protocol. 

•  Destination  Port.  This  is  the  local  port  for  the  application,  at  the  receiver, 
using  the  TCP  transport  protocol. 

•  UDP  Length.  The  length  of  the  UDP  header  plus  the  data  field. 

•  Checksum.  The  error  detection  code  for  the  header  and  data. 

3.  ATM 

a.  ATM  Fundamentals 

Like  TCP,  ATM  is  a  connection-oriented  communication  service.  How¬ 
ever,  ATM  is  lower  in  the  OSl  model  because  ATM  is  also  involved  in  routing  from 
the  source  to  the  destination.  Due  to  its  multi-layer  functionality,  ATM  does  not  “fit” 
cleanly  into  the  OSI  communications  model.  The  conventional  view  is  that  the  ATM 
protocol  is  a  consolidation  of  the  OSI  Network  and  Data  Link  layers. 
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There  are  multiple  sublayers  within  the  ATM  protocol  and  this  section 
will  discuss  several  of  them  in  detail.  Figure  4  shows  the  International  Telecommu¬ 
nication  Union  Telecommunication  Standardization  Sector  (ITU-T)  protocol  reference 
model  for  ATM.  We  provide  this  figure  as  a  conceptual  reference  for  the  reader  when 
we  begin  discussing  the  sublayers  in  detail. 


The  basic  element  of  the  ATM  layer  is  a  Virtual  Channel  Connec¬ 
tion  (VCC).  When  data  is  passed  to  the  ATM  layer,  a  VCC  is  established  between 
the  source  and  destination.  This  VCC  transports  the  user’s  datagrams,  along  with 
control  signals  that  support  the  link  and  manage  the  overall  network.  After  the  user’s 
datagram  has  been  transmitted,  the  VCC  is  dismantled  and  its  resources  are  returned. 
This  process  of  connection  and  disconnection  is  extremely  fast  because  much  of  it  is 
incorporated  in  the  ATM  switch  and  network  hardware. 

The  ATM  protocol  includes  a  Virtual  Path  Connection  (VPC) 
which  is  responsible  for  bundling  VCCs  that  have  the  same  endpoint.  To  enhance 
overall  ATM  performance,  all  of  the  VCCs  in  the  same  VPC  are  treated  as  a  single 
entity  within  the  network.  By  reserving  additional  capacity  on  a  VPC,  in  anticipation 
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of  later  VCCs,  new  VCCs  can  be  established  by  simple,  low  overhead,  control  functions 
executed  only  at  the  endpoints.  Figure  5  depicts  the  relationship  between  the  physical 
route  or  cable,  the  virtual  path  (VPC)  and  the  virtual  channel  (VCC). 

Because  ATM  was  primarily  designed  for  use  over  fiber  optic  networks, 
and  such  networks  are  very  reliable,  the  ATM  protocol  provides  no  mechanism  for 
error  control  or  error  correction  [Ref.  1].  These  functions  are  left  to  the  higher  layer 
protocols.  Additionally,  ATM  provides  no  mechanisms  for  acknowledgments;  this 
function  is  also  left  to  the  higher  layer  protocols.  Of  course,  there  are  occasional 
errors  within  fiber  optic  networks,  but  the  probability  is  so  low  that  the  ATM  protocol 
expects  the  higher  layer  to  re-transmit  an  entire  message  if  it  detects  an  error. 

(0] 

Figure  5.  The  relationship  between  Physical  Route,  Virtual  Path  Connection,  and 
Virtual  Channel  Connection  (Derived  From  [Ref.  6]). 

Unlike  TCP  and  UDP,  ATM  packets  are  all  fixed  length,  and  they  are  re¬ 
ferred  to  as  cells.  Each  ATM  cell  contains  a  48-byte  data  field  (payload)  and  a  5-byte 
header;  it  is  extremely  small  compared  to  the  average  TCP  or  UDP  packet.  The  Inter¬ 
national  Telecommunication  Union  (ITU)  standard  defines  two  different  packet  header 
formats  for  ATM  cells.  One  format,  called  User-Network  Interface  (UNI),  is  required 
at  the  boundary  between  the  user  host  equipment  and  the  ATM  network  (non-ATM 


Physical  Route 
or  Fiber 
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to  ATM  equipment  interface).  The  second  format,  called  Network-Network  Interface 
(NNI)  is  used  within  an  ATM  network  (ATM  to  ATM  equipment  interface).  [Ref.  1] 
Figure  6  depicts  the  two  different  ATM  cell  header  formats. 
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Figure  6.  (a)  ATM  UNI  celT header  format,  (b)  ATM  NNI  cell  header  format 

(From  [Ref.  7]). 


Each  of  the  fields  within  the  ATM  cell  header  are: 

•  Generic  Flow  Control.  This  field  is  only  present  in  cells  sent  from  a  host 
to  an  ATM  network  and  is  currently  not  used-  In  the  future,  it  could  control 
cell  flow  or  identify  priority  levels. 

•  Virtual  Path  Identifier.  This  field  identifies  the  virtual  path  for  this  cell. 

•  Virtual  Channel  Identifier.  The  VCI  identifies  a  particular  virtual  channel 
within  the  selected  virtual  path. 

•  Payload  Type  Identifier.  ATM  cells  may  carry  user  data  or  ATM  manage¬ 
ment  data.  This  field  identifies  the  type  of  data  contained  within  the  cell. 

•  Cell  Loss  Priority  (CLP).  The  CLP  bit  flag  distinguishes  high  and  low 
priority  data  cells.  A  congested  ATM  network  will  first  attempt  to  drop  cells 
with  CLP  values  of  1  before  dropping  those  with  a  CLP  values  of  0. 

•  Header  Error  Check.  The  error  detection  code  which  is  used  to  detect  errors 
in  the  header  only. 
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When  analyzing  the  properties  of  the  ATM  protocol,  we  define  a  data 
stream  as  a  group  of  cells  that  are  sent  from  one  user  application  to  another.  One 
of  ATM’s  strengths  is  its  ability  to  switch  between  data  streams  extremely  efficiently 
because  of  the  small,  fixed  length  of  ATM  cells.  When  a  higher  priority  data  stream 
needs  to  interrupt  a  lower  priority  one,  the  higher  priority  stream  must  only  wait  for 
the  completed  transmission  of  a  relatively  small  data  segment. 

The  most  common  method  for  establishing  priorities  within  an  ATM 
network  is  by  using  a  designator  known  as  the  Class  of  Service.  Using  the  data 
characteristics  previously  defined,  the  ITU-T  recommendation  defines  four  classes 
of  ATM  service:  Class  A,  Class  B,  Class  C  and  Class  D.  Figure  7  illustrates  the 
differences  between  each  of  these  service  classes. 


Class  A 

Class  B 

Class  C 

Class  D 

Timing  between 

source  and 

destination 

Required 

Not  Required 

Bit  Rate 

Constant 

Variable 

Connection  Mode 

Connection  Oriented 

Connectionless 

Figure  7.  The  differences  between  each  of  the  ATM  service  classes  (Modified 
From  [Ref.  1]). 

b.  ATM’s  AAL  Layer 

The  AAL  sublayer  sits  just  above  the  ATM  sublayer  and  maps  the  user 
data,  control  data,  and  management  data  into  the  information  field  of  one  or  more 
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ATM  cells.  Because  there  exists  a  vast  difference  between  TCP/UDP  packets  and 
ATM  cells,  the  ATM  protocol  contains  a  specialized  sublayer  to  convert  transport 
protocol  packets  to  ATM  cells.  This  sublayer  is  called  the  ATM  Adaptation  Layer 
(AAL). 

The  AAL  layer  consists  of  several  different  AAL  types  that  are  closely 
aligned  to  the  different  classes  of  ATM  service.  Table  II  defines  each  of  the  AAL 
types.  This  thesis  is  primarily  focused  on  the  AAL  Type  5  service. 


AAL  Type 

Data  Characteristics 

AAL  1 

Constant  Bit  Rate  services 

AAL  2 

Variable  Bit  Rate  services 

AAL  3/4 

Data  which  is  sensitive  to  loss  but  not  to  delay 

AAL  5 

Less  sensitive  to  loss  than  AAL  3/4  but  not  sensitive 
to  delay 

Table  II.  ITU-T  AAL  type  recommendations. 


All  of  the  AAL  layers  are  subdivided  into  two  sub-sublayers:  the  Seg¬ 
mentation  and  Reassembly  (SAR)  Sublayer  and  Convergence  Sublayer  (CS). 
The  CS  layer  is  further  subdivided  into  a  Service  Specific  Convergence  Sublayer 
(SSCS)  and  a  Common  Part  Convergence  Sublayer  (CPCS).  The  relationship 
between  each  of  these  layers  is  depicted  in  Figure  8. 

We  now  address  how  all  of  the  sublayers  within  the  AAL  layer  function 
together  to  convert  a  large  TCP/UDP  packet  into  ATM  cells  for  transport  across  a 
network.  The  SSCS  is  protocol-specific  and  may  include  message  framing  and  error 
correction.  The  CPCS  within  AAL5  begins  by  padding  the  user  data  packet  to  make 
the  entire  message  a  multiple  of  48  bytes.  The  CPCS  then  adds  one  byte  for  the 
User-to-User  field,  one  byte  for  Common  Part  Indicator,  two  bytes  for  the  user  data 
length,  and  four  bytes  for  error  detection.  The  CPCS  Protocol  Data  Unit  is  depicted 
in  Table  III. 
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Figure  8.  The  relationship  between  ATM,  AAL,  SAR,  CS,  CPCS,  and  SSCS  sublayers 
(Derived  From  [Ref.  4]). 


User  Data 

Pad 

UU 

CPI 

Length 

CRC 

Table  III.  CPCS-PDU  format  for  AAL5 


The  Segmenting  and  Reassembly  (SAR)  layer  is  responsible  for  differ¬ 
ent  functions  depending  on  whether  it  is  at  the  receiving  or  transmitting  end  of  the 
network.  At  the  transmission  end  of  the  network,  the  SAR  segments  large  data  pack¬ 
ets  into  48-byte  segments.  Each  48-byte  segment  is  passed  down  to  the  ATM  layer 
where  they  are  placed  into  individual  ATM  cells.  At  the  receiver  end  of  the  network, 
the  SAR  reassembles  the  48-byte  segment  into  the  large  data  packet  and  forwards  the 
large  data  packet  to  the  receiver’s  application  layer. 

c.  Transporting  ATM  cells  across  an  ATM  Network 
After  the  AAL  layer  has  converted  calls  from  ATM  and  non-ATM  into 
48-byte  segments,  the  cells  are  transported  from  source  to  the  receiver.  Before  the  cells 
can  be  transmitted  across  the  physical  layer,  all  ATM  switches  between  the  source 
and  destination  must  establish  a  connection.  This  section  describes  the  process  for 
connection  setup  when  a  physical  route  exists  from  source  to  receiver  and  a  special 
virtual  circuit  exists  for  signaling  within  that  ATM  network. 
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Virtual  circuits  are  established  by  using  the  special  signaling  circuit  and 
the  six  message  types  defined  in  Table  IV  [Ref.  7].  A  signaling  message  may  be  sent 
by  a  host  (source  or  receiver)  or  by  switches  within  the  network.  A  call  request  is 
a  signal  from  a  higher  level  application  layer  to  the  AAL  layer  indicating  that  data 
needs  to  be  sent  across  the  network.  A  call  request  begins  when  the  source  host  sends 
a  SETUP  message  over  the  signaling  circuit;  this  process  is  depicted  in  Figure  9. 
The  first  switch  in  the  network  then  sends  a  SETUP  message  to  the  next  switch  in 
the  network  and  sends  a  CALL  PROCEEDING  back  to  the  source.  As  the  SETUP 
message  works  its  way  through  the  network,  each  switch  forwards  a  SETUP  message 
to  the  next  switch  and  sends  a  CALL  PROCEEDING  back  to  the  previous  switch. 


Message 

Meaning  at  Host 

Meaning  within  Network 

SETUP 

Request  a  circuit 

Incoming  call 

CALL  PROCEEDING 

Network  saw  call 

Attempted  to  establish 
call 

CONNECT 

Network  accepts  call 

Requested  call  was 
accepted 

CONNECT  ACK 

Connect  message  received 

Call  established 

RELEASE 

Terminating  the  call 

Call  terminated 

RELEASE  COMPLETE 

Ack  for  RELEASE 

Ack  for  RELEASE 

Table  IV.  ATM  Messages  used  for  connection  establishment  and  release  (From  [Ref. 

7]). 


When  the  SETUP  message  finally  reaches  the  destination  ATM  Switch, 
the  destination  transceiver  responds  with  a  CONNECT  message  if  the  -destination 
accepts  the  call  request.  The  CONNECT  message  works  its  way  back  to  the  source  in 
a  manner  similar  to  the  SETUP  message,  except  in  the  reverse  order.  At  each  switch 
within  the  network,  a  CONNECT  ACK  message  is  sent  to  the  previous  switch.  When 
the  CONNECT  message  arrives  at  the  source,  the  source  also  sends  a  CONNECT 
ACK  message  to  the  previous  switch  in  the  network. 
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Terminating  a  virtual  circuit  is  simpler  than  establishing  it.  The  source 
sends  a  RELEASE  message  to  the  first  switch  in  the  network.  This  message  propagates 
through  the  network  with  a  RELEASE  ACK  message  sent  at  each  hop  along  the  route. 


Source  IDS  Switch 


Uplink 


Dniink  WFA  Switch  Destination 


_ _ Setup  ^ 

Setup 

_ _ Setup _ _ 

_ 

_ Setup  ^ 

Setup  ^ 

- Connect  Ari^ 

- Connect  Ack 

CoTvnect^__^ 

Connect  Ar^ 

Connect  Arir 

- Connect  Ari- 

(a)  Call  Establishment  Sequence 


Figure  9.  (a)  The  sequence  of  signaling  messages  for  establishing  an  ATM  virtual 
channel,  (b)  Tlie  sequence  of  signaling  messages  to  release  an  ATM  virtual  channel 
(From  [Ref.  7]). 
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III. 


OVERVIEW  OF  THE  BADD  PROGRAM 


A.  OVERVIEW 

We  first  provide  a  general  description  of  The  Battlefield  Awareness  and 
Data  Dissemination  (BADD)  system.  Subsequent  sections  of  this  chapter  provide 
a  more  detailed  description  of  its  major  components  [Ref.  8].  The  BADD  project 
is  an  Advanced  Concepts  Technology  Demonstration  (ACTD)  sponsored  by 
the  Defense  Advanced  Research  Projects  Agency  (DARPA).  BADD  uses 
commerci«d  off-the-shelf  (COTS)  systems  to  support  the  U.S.  military’s  need  for  total 
battle  awareness,  that  is,  to  provide  information  where  it  is  needed,  in  the  correct 
format,  and  in  a  timely  and  cost  effective  manner.  The  goal  of  BADD  is  to  empower 
war-fighters,  from  the  Task  Force  Commander  through  the  Battalion  Commander  and 
below,  with  information.  Such  information  will  be  delivered  using  advanced  dissem¬ 
ination  technologies.  The  BADD  system  consist  of  the  following  major  components; 

•  the  Information  Dissemination  Server  (IDS), 

•  the  Satellite  Broadcast  System, 

•  the  Tactical  System/ Warfighter  Associate  (WFA),  and 

•  the  Reachback  Link. 

An  overview  of  the  interactions  of  these  components  is  depicted  in  Figure  10 
and  is  summarized  below. 

The  IDS  functions  as  the  central  repository  for  processing,  storage,  and  re¬ 
trieval  of  data.  The  Satellite  Broadcast  System  forwards  data  from  the  IDS  to 
multiple  tactical  users,  via  satellite  communication.  Data  broadcasted  over  the  satel¬ 
lite  link  is  collected  and  stored  at  the  tactical  units  by  a  suite  of  automation  equip¬ 
ment  called  the  Warfighter  Associate  (WFA).  The  data  is  then  made  available 
to  the  warfighter’s  Local  Area  Network  (LAN)  via  the  Tactical  Internet  (TI).  The 
Reachback  Link  allows  tactical  units  to  forward  important  data,  such  as  location 
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information  or  unmanned  aerial  video,  back  to  the  IDS  for  timely  dissemination  to 
other  tactical  forces.  In  addition,  it  provides  a  means  for  the  tactical  units  to  re¬ 
quest  information  from  the  IDS.  Some  units  will  not  have  a  reachback  link  available 
to  communicate  to  the  IDS  directly  and  will  relay  their  request  to  the  closest  unit 
with  reachback.  These  units'  will  have  the  ability  to  “listen  in”  to  broadcasts,  filter 
out  unwanted  data,  and  save  what  they  need.  Next  we  will  examine  each  of  these 
components  in  greater  detail. 


Global  Broadcast  System 


Reachback  Link 

Figure  10.  BADD  Overview  (From  [Ref.  8]). 


B.  INFORMATION  DISSEMINATION  SERVER 

The  Information  Dissemination  Server  (IDS)  provides  management,  storage, 
and  dissemination  to  the  broadcast  uplink  facility.  The  IDS  is  located  at  DARPA’s 
Advanced  High  Performance  Computing  Applications  (AHPCA)  lab  facil¬ 
ity.  The  IDS  works  in  conjunction  with  the  Warfighter  Associate  (WFA)  to  sat¬ 
isfy  the  information  needs  of  the  lower  echelon  commanders.  The  IDS  receives  and 
stores  information  from  in-theater  via  the  reachback  links,  and  can  access  information 
from  multiple  resources,  such  as  CNN,  national  intelligence  sources,  and  the  National 
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Weather  Service,  in  the  Washington,  D.C.  area.  It  forwards  data  to  the  field  in  two 
ways.  The  first  is  by  broadcasting  the  data  that  is  stored  locally.  The  second  way  is 
by  acting  as  an  intermediate  communication  hub,  forwarding  data  from  either  a  data 
repository  or  the  reachback  link  without  storing  the  data  locally. 

The  IDS  has  the  functionality  to  integrate  data  from  various  resources  and 
disseminate  a  more  comprehensive  view  of  the  battlefield  to  the  Battalion  Commander 
in  the  field.  One  of  the  ways  the  IDS  accomplishes  this  mission  is  through  intelligently 
prepositioning  information  at  the  WFA  for  rapid  retrieval.  Such  prepositioning  is 
referred  to  as  a  Push  operation.  Another  way  the  IDS  satisfies  the  needs  of  the  user 
is  through  a  Pull  operation.  A  pull  operation  is  when  the  IDS  forwards  information 
to  be  broadcast  in  order  to  satisfy  a  query  from  the  field  over  the  reachback  link. 

Figure  11  depicts  a  high-level  diagram  of  the  flow  of  data  between  the  major 
subcomponents  of  the  IDS.  We  will  elaborate  on  each  of  these  subcomponents  in  the 
remainder  of  this  section.  [Ref.  8] 


Information 
Sources  and  Data 
Repositories 

Figure  11.  IDS  Components  (From  [Ref.  3]). 


1.  Information  Sources  and  Data  Repositories 

Figure  11  shows  that  there  are  multiple  sources  of  information  coming  into  the 
IDS.  The  sources  we  enumerate  are  not  inclusive  and  are  meant  to  show  the  variety 
of  data  types  that  can  be  made  available  through  the  BADD  architecture.  Table  V 
describes  each  of  the  sources  depicted  in  that  figure.  [Ref.  3] 


Source 

Description 

IMETS 

Integrated  Meteorological  System  weather  data 
from  the  division  Tactical  Operations  Center  (TOC). 

UAV 

Unmanned  Aerial  Vehicle  broadcast  from  tactical 
units.  Forwarded  live  for  wider  dissemination. 

WHITE 

BOARD 

Commander’s  Whiteboard.  Provides  graph  for 
the  commander  to  use  to  elaborate  on 
orders /instructions. 

DMA 

Defense  Mapping  Agency  map  information. 

Table  V.  IDS  Information  Sources  (From  [Ref.  3]). 


2.  Source  Interface 

The  Source  Interface  integrates  the  data  that  it  receives  from  multiple  data 
sources,  including  the  reachback  link.  To  accomplish  this  task  it  uses  FORE  ATM 
switches  that  allow  inputs  from  both  ATM  sources  and  CISCO  Routers.  CISCO 
Routers  allow  input  from  TCP/IP/UDP  sources. 

3.  Search  Manager 

The  Search  Manager  retrieves  information  from  the  remote  repositories  in  or¬ 
der  to  satisfy  Priority  Information  Requirements  (PIR)  from  the  tactical  commander. 
To  accomplish  this  task  it  maintains  directories  indicating  which  resources  are  avail¬ 
able  from  each  of  the  distributed  repositories. 

4.  Information  Dissemination  Repository 

The  Information  Dissemination  Repository  provides  a  very  large  (tera¬ 
byte  to  peda-byte)  on-line  storage  capability  and  is  optimized  to  service  queries  for 
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multimedia  data.  This  subcomponent  supports  the  use  of  distributed  heterogeneous 
axchives.  These  archives  can  be  geographically  separated,  can  be  forwarded  to  the  IDS 
by  different  communication  protocols  (TCP/IP/UDP),  and  can  contain  data  ranging 
from  small  text  files  to  very  large  video  files. 

5.  Information  Integration  Manager 

The  Information  Integration  Manager  correlates  data  from  the  Informa¬ 
tion  Dissemination  Repository  in  order  to  integrate  and  validate  data  from  different 
sources.  It  also  searches  for  redundancies  in  the  data  in  order  to  eliminate  them  and 
provide  both  a  more  efficient  data  transfer  and  a  more  user-friendly  interface. 

6.  Transmission  Manager 

The  Transmission  Manager  maximizes  the  probability  of  reliable  delivery 
across  simplex,  error-prone  satellite  channels.  It  optimizes  the  dissemination  to  tactical 
commanders  by  utilizing  algorithms  and  heuristics  that  send  the  highest  priority  data 
during  peeik  periods  and  smartly  push  data  during  low  utilization  periods. 

Determining  when  to  push  data  is  referred  to  as  the  Data  Staging  Problem. 
H.  J.  Siegel  and  some  of  his  Ph.D.  students  at  the  University  of  Purdue  are  working 
to  resolve  this  problem  [Ref.  9].  Their  efforts  focus  on  determining  the  best  data  to 
cache,  given: 

•  the  priority  of  data  and  its  perishablility, 

•  the  dynamic  nature  of  requests  and  network  congestion,  and 

•  limits  on  bandwidth  and  data  storage. 

They  are  examining  the  use  of  mathematical  algorithms,  such  as  Dijkstra’s 
Algorithm,  to  improve  the  performance  of  BADD  transmission  management. 

C.  SATELLITE  UPLINK  AND  BROADCAST  SEGMENT 

The  Satellite  Uplink  facility  is  connected  to  the  IDS  via  high  speed  links 
(T3)  and  is  the  insertion  point  for  data  into  the  broadcast  link  connecting  the  IDS 
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to  the  Warfighter  Associate.  This  broadcast  facility  is  responsible  for  providing  efl&- 
cient  utilization  of  the  link  while  ensuring  that  the  priority  scheme  for  transmission  is 
not  violated.  The  broadcast  is  transmitted  over  a  geosynchronous  Ku-Band  satellite, 
providing  a  direct  link  from  the  uplink  system  to  the  battalions  in  the  field.  The 
broadcast  has  two  channels,  one  for  video  and  the  other  for  data.  The  data  channel 
is  comprised  of  numerous  data  channels  multiplexed  together  to  form  one  wideband 
channel.  Figure  12  depicts  the  interactions  of  the  major  subcomponents  of  the  Broad¬ 
cast  Subsystem;  each  of  these  subcomponents  is  addressed  in  this  section. 


Figure  12.  Broadcast  Segment  (Derived  From  [Ref.  lOj). 


1.  Broadcast  Management  Center 

The  Broadcast  Management  Center  (BMC)  software  is  responsible  for 
collecting  all  information  to  be  broadcast  to  BADD  tactical  users.  The  data  received 
at  the  BMC  will  include  information  requested  by  tactical  users  (warrior  pull)  and 
time-sensitive,  intelligently-selected  (smart  push)  information  for  broadcast  to  tactical 
users. 
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The  BMC  will  decide  answers  to  the  following  questions: 


•  What  information  needs  to  be  broadcast? 

•  What  priority  is  the  data  to  be  broadcast? 

•  What  bandwidth  is  needed  for  the  data? 

•  When  should  the  data  arrive  at  the  Warfighter  Associate? 

If  a  message  cannot  be  broadcast  within  the  BMC-assigned  parameters,  the 
BMC  must  review  the  information  and  determine  whether  the  information  can  be 
broadcast  at  a  lower  priority  or  whether  the  information  should  be  discarded. 

2.  Uplink  Information  Manager 

Within  the  BMC,  the  Uplink  Information  Manager  (UIM)  manages  all 
information  for  broadcast  through  the  ATM  switch.  The  UIM  is  primarily  concerned 
with  maximizing  throughput,  given  a  priority  level.  Closely  coordinating  with  the 
ATM  switch  to  determine  the  dynamic  ATM  capacity,  the  UIM  attempts  to  schedule 
all  data  transmissions  to  achieve  data  throughput  of  the  highest  priority  messages.  If 
the  UIM  cannot  schedule  the  broadcast  of  a  message  within  the  assigned  constraints, 
it  will  return  the  message  to  the  Broadcast  Manager  for  resolution. 

3.  Asynchronous  Transfer  Mode  (ATM)  Switch 

The  ATM  switch  currently  used  is  the  Integrated  Systems  Technology  (1ST) 
Low  Data  Rate  (LDR)  Model  LDR-IOOS  [Ref.  8].  It  supports  both  ATM  and  non- 
ATM  links,  providing  multimedia,  video  teleconferencing  (VTC),  mobile  subscriber 
equipment  (MSE),  and  tactical  packet  network  (TPN)  support.  The  system  contains 
four  special  buffers  to  minimize  the  delay  of  the  constant  bit  rate  (CBR)  traffic  and 
allow  for  smoothing  of  peak  data  rates.  It  also  contains  a  TAXI  interface  card  that 
supports  connections  for  one  serial  system  and  one  parallel  port.  The  previous  chapter 
of  this  thesis  described  the  ATM  protocol  in  detail. 
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4.  Unclassified  Video 

This  unclassified  video  consists  of  CNN  news  broadcasts,  Armed  Forces  Ra¬ 
dio  and  Television  broadcasts,  unclassified  Unmanned  Aerial  Vehicle  broadcasts,  and 
other  unclassified  video  broadcasts.  The  current  configuration  allocates  half  of  the 
total  transmission  capability  to  transmission  of  unclassified  video. 

5.  Multiplexor  (MUX) 

The  30  Mbps  Multiplexor  will  multiplex  the  unclass  video  and  ATM  data  into 
a  single  data  stream  for  broadcast  transmission  over  the  Global  Broadcast  System. 

6.  Global  Broadcast  System 

Currently,  the  Global  Broadcast  System  (GBS)  uses  a  commercial  Telestar 
401  Ku-band  satellite  transponder,  in  geosynchronous  orbit,  that  provides  an  effective 
transmission  capacity  of  23.6  Mbps.  This  single  satellite  in  the  GBS  constellation  is 
capable  of  providing  coverage  over  the  continental  United  States. 

D.  TACTICAL  LEVEL  SUBSYSTEM 

Tactical  units  at  the  battalion  level  will  have  a  Receive  Terminal  that  consists 
of  a  satellite  antenna  dish,  an  amplifier /converter  called  a  Low-Noise  Block  (LNB) 
converter,  two  Integrated  Receiver  Decoders  (IRD)  that  provide  the  decoding  of  either 
a  data  or  video  signal  stream,  and  an  ATM  switch  that  provides  the  first  level  of  filter¬ 
ing,  a  KG- 194 A  Decryption  Device,  and  the  Warfighter  Associate.  Figure  13  depicts 
a  high-level  diagram  of  the  major  subcomponents  of  the  Tactical  Level  Subsystem. 
Each  of  these  subcomponents  is  addressed  in  this  section. 

1.  GBS  Receive  Equipment 

The  receive  equipment  consists  of  a  1.2  meter  antenna  dish  connected  into 
a  Low  Noise  Block  (LNB)  converter.  The  LNB  is  a  converter  taking  the  Ku-Band 
(11.7-12.2  GHz)  satellite  transmission  and  converting  it  to  L-Band  (0.39-1.6  GHz). 
This  segment  also  includes  an  Integrated  Receiver  Decoder  (IRD)  that  converts  the 
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Figure  13.  Tactical  Segment  (Derived  From  [Ref.  8]). 


signal  to  a  parallel  data  stream  for  forwarding  to  the  ATM  Switch. 

2.  Splitter 

The  Splitter  accomplishes  one  simple  function.  It  takes  the  non-ATM  signal 
on  the  broadcast  and  splits  it  off  for  injection  into  the  tactical  internet,  while  allowing 
the  ATM  transmissions  to  pass  through  to  the  ATM  Switch.  Non- ATM  signals  include 
CNN,  AFRTS  and  other  commercial  television  broadcasts. 

3.  Downlink  Information  Manager  (DIM) 

The  Downlink  Information  Manager  (DIM)  is  the  subcomponent  of  the 
Warfighter  Associate  that  determines  whether  the  information  currently  being  broad¬ 
cast  is  of  interest  to  the  tactical  user.  The  WFA  user  customizes  his  environment 
based  upon  a  “television  guide-like”  broadcast  sent  over  the  a  predefined  control 
channel  on  the  satellite  link  displaying  the  scheduled  broadcast.  This  function  is  crit¬ 
ical  because  the  Warfighter  Associate  only  has  limited  local  storage  capabilities,  and 
additionally,  the  tactical  user  does  not  want  to  be  flooded  with  irrelevant  data. 
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4.  ATM  Switch 

The  switch  used  is  the  same  1ST  LDR-lOOs  that  is  used  at  the  uplink  facility. 
It  provides  all  of  the  same  functions  described  above,  but  in  support  of  reception  of 
the  ATM  broadcast  instead  of  its  transmission. 

5.  Warfighter  Associate  (WFA) 

The  Warfighter  Associate  is  the  heart  of  the  BADD  system  from  the  tactical 
commander’s  perspective.  It  provides  his  local  data  repository  for  quick  access  to  the 
most  important  data.  The  WFA  also  provides  information  integration  and  battlefield 
functionality.  The  Warfighter  Associate  Workstation  is  an  Ultra-SPARC  unit  respons¬ 
ible  for  filtering  the  incoming  GBS/BADD  data  based  upon  specific  profiles,  areas  of 
interest,  and  areas  of  operations.  Workstations  will  vary  in  their  configuration  based 
on  the  service,  but  a  typical  workstation  has  64  megabytes  of  random  access  memory 
(RAM)  and  10.4  gigabytes  (GB)  of  hard  disk  storage  with  2  GB  internal  and  8.4  GB 
on  external  disks. 

The  WFA  workstation  provides  the  following  functions: 

•  Stores  data  in  a  local  repository, 

•  Provides  users  with  applications  and  interfaces, 

•  Performs  information  integration  operations, 

•  Provides  a  graphical  display  for  battlefield  visualization,  and 

•  Provides  access  to  other  users  on  the  tactical  LAN. 

6.  Tactical  Internet 

The  Tactical  Internet  (TI)  is  a  subcomponent  of  the  Army  Battle  Com¬ 
mand  System  (ABCS)  that  focuses  on  providing  support  for  battle  command  at 
the  brigade  level  and  below.  The  TI  is  focused  on  providing  situational  awareness  to 
warfighters  at  lower  echelons  through  the  use  of  Applique  devices.  Applique  devices 
that  are  comprised  of:  1.)  a  computer  host  and  software  package;  and  2.)  a  tactical 
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radio  system  that  provides  duplex  information  flow  between  a  platform  (i.e.,  tank,  ar¬ 
tillery,  or  aircraft)  or  an  individual  soldier  and  the  division  level  of  command.  System 
Integration  Vans  (SIVs)  plan  and  manage  the  use  of  the  Tactical  Internet  and  take 
inputs  from  the  following  systems: 

•  Enhanced  Position  Location  Reporting  System  High  Speed  Integrated  Circuit 
(EPLRS  VHSIC), 

•  Surrogate  Data  Radio  (SDR), 

•  Single  Channel  Ground  and  Airborne  Radio  System  (SINCGARS)  System  Im¬ 
provement  Program  (SIP), 

•  Mobile  Subscriber  Equipment  (MSE), 

•  BADD,  and 

•  Interfaces  to  Tactical  Operations  Center  (TOC)  Local  Area  Networks. 

E.  THE  REACHBACK  SUBSYSTEM 

The  Reachback  Link  provides  the  connectivity  from  the  tactical  unit  to  the 
IDS  and  has  two  different  sublinks.  A  Trojan  Spirit  Satellite  communication  system 
provides  an  aggregate  transmission  rate  of  1.544  Mbps  from  the  Brigade  TOC  to  the 
IDS  LAN.  This  first  system  utilizes  an  unclassified  ethernet-based  sublink  running 
the  IP  protocol.  It  requires  a  Tactical  End-to-End  Encryption  Device  (TEED) 
because  it  tunnels  through  a  an  operationally  classified  network.  Unmanned  aerial 
vehicle  imagery,  operational  and  intelligence  overlays,  and  IMETS  data  are  sent  over 
this  sublink.  The  latest  testing  results  from  an  exercise  in  November  1996  required 
that  the  largest  packet  size  transported  from  the  Brigade  WFA  to  the  IDS  was  1472 
bytes.  The  average  round  trip  time  for  a  64-byte  packet,  from  the  Brigade  WFA 
through  the  reachback  link  and  broadcast  link  back  to  the  WFA,  was  564  ms  [Ref. 
11). 

The  second  system  is  ATM-enabled  sublink  and  uses  a  KG-194A  encryption 
device  to  provide  secure  data  transmission.  It  operates  at  768  Kbps  and  sends  one¬ 
way  video  stream  and  one-way  collaborative  planning  to  disseminate  the  Brigade 


33 


Commander’s  Intent  with  real-time  video,  audio,  and  electronic  whiteboarding.  The 
round  trip  time  for  a  64-byte  packet  on  this  subnet  was  808  ms.  Jeffrey  Carpenter  and 
Jim  Galanis,  Electronics  Engineers  with  the  US  Army  Commxmications-Electronics 
Command  (CECOM),  recommended  examining  the  effects  of  reducing  the  bit  rate  to 
384  Kbps  in  order  to  provide  the  Ethernet  sublink  with  more  bandwidth,  based  on 
their  November  1996  experience  [Ref.  11]. 

Figure  14  depicts  a  high-level  diagram  of  the  major  subcomponents  of  the 
Reachback  Subsystem.  Each  of  these  subcomponents  is  addressed  in  this  section. 

Reachback  Link 


Figure  14.  Reachback  Components 


1.  Surrogate  Digital  Radio 

The  Surrogate  Digital  Radio  (SDR)  is  a  state-of-the-art  digital  radio  that 
provides  communication  between  the  TOCs,  the  alternate  TOCs,  and  command  and 
control  platforms  [Ref.  8].  It  has  two  major  subcomponents;  a  secure  packet  radio 
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(SPR)  and  a  wireless  integrated  services  digital  network  interface  unit  (WIU).  The 
SPR  is  a  spread  spectrum  modulation  radio  that  operates  in  the  UHF  range  and  has  a 
data  throughput  capacity  of  190  Kbps  and  embedded  communications  security.  The 
WIU  is  an  80486  lightweight  computer  providing  a  synchronous  serial  communication 
card  that  interfaces  with  the  SPR  and  the  TOC’s  ethernet  LAN. 

2.  Brigade  ATM  Switch 

The  BDE  ATM  Switch  provides  a  tactical  ATM  backbone  switching  support 
for  all  tactical  users.  The  switch  provides  connections  for  wideband  fiber  optics,  syn¬ 
chronous  optic  network  (SONET)  radios,  employed  tactical  digital  radios,  and  digital 
transmission  group  (DTG)  network  interfaces.  The  LDR-100,  which  was  described 
earlier,  is  once  again  the  chosen  hardware  for  this  switch. 

3.  Trojan  Spirit 

The  Trojan  Spirit  provides  secure  satellite  voice  and  data  communications 
from  the  forces  in  the  field  back  to  the  IDS  [Ref.  12].  It  is  a  highly  mobile  system 
mounted  on  the  back  of  a  High  Mobility  Military  Wheeled  Vehicle  (HMMWV)  Shelter 
with  a  2.4  meter,  C  through  Ku-band,  Satellite  Antenna.  It  tows  a  5.5  meter  X-Band 
satellite  communication  antenna  mounted  on  an  accompanying  trailer.  It  can  provide 
14  channels  of  digital  voice  or  support  digital  data  subscribers  over  a  Tl  link  (1.544 
Mbps). 

4.  Satellite  System 

The  Trojan  Spirit  transmits  its  data  to  a  variety  of  satellite  platforms  including 
INTELSAT,  GSTAR,  and  PANAMSAT.  Transmissions  on  these  frequencies  and  other 
satellite-lettered  bands  are  listed  in  Table  VI. 

5.  Fort  Belvoir  Trojan  Switch 

The  Fort  Belvoir  Trojan  Switch  receives  data  from  the  Trojan  Spirit  in  the  field 
and  forwards  data  via  Defense  Information  Systems  Network  Leading  Edge  Services 
(DISN  LES). 
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Letter 

Design 

Band 

Freq  Range 
(GHz) 

Bandwidth 

(MHz) 

Use 

L 

50 

Commercial,  Military 

S 

90 

Tracking,  Telemetry 
and  Command 

C 

SHF 

500 

Commercial 

X 

SHF 

5.2-10.9 

500 

Military 

Ku 

SHF 

10.9-17.25 

500 

Commercial 

Ka 

SHF 

17.5-30 

2500 

1000 

Commercial 

Military 

Table  VI.  Satellite  Lettered  Band. 


6.  AHPCA  ATM  Switch 

The  AHPCA  ATM  Switch  in  Arlington,  Virginia  processes  the  signals  from 
the  Fort  Belvoir  switch  and  forwards  them  to  the  proper  location  within  the  IDS.  The 
FORE  ASX-200  BX  ATM  switch  provides  the  capabilities  to  function  as  a  LAN  back¬ 
bone  [Ref.  13].  These  switches  provide  advanced  reliability  and  fault  tolerance,  and 
can  support  up  to  24  clients,  servers,  and  LAN  devices  such  as  hubs,  routers  or  LAN 
switches.  They  execute  ForeThought  Internetworking  Software  that  provides  connec¬ 
tion  management  features  such  as  on-demand  switched  virtual  circuits  (SVCs),  both 
User  Network  Interface  (UNI)  and  Network  Network  Interface  (NNI),  and  transparent 
support  for  existing  LAN  applications  that  use  IP-over-ATM  and  LAN  emulation. 

7.  Summary 

We  have  now  reviewed  all  current  components  and  subcomponents  of  the 
BADD  Program.  We  want  to  emphasize  that  this  is  a  dynamic  experimental  ar¬ 
chitecture  with  components  being  added  and  removed.  Our  description  of  the  system 
should  be  viewed  as  a  single  instantiation,  as  of  April  21,  1997.  Individual  components 
and  even  entire  subsystems  may  change.  In  the  next  chapter  we  review  some  of  the 
scheduling  algorithms  that  we  considered  to  integrate  into  the  BADD  Architecture. 
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IV.  INTELLIGENT  SCHEDULING 


A.  INTRODUCTION 

In  Chapter  II  we  described  ATM’s  signaling  procedures  for  virtual  channel 
setup  and  tear-down.  In  this  chapter  we  will  examine  the  application  of  some  com¬ 
monly  used  scheduling  heuristics  that  we  expect  will  improve  the  throughput  and 
fairness  of  the  BADD  network’s  ATM  configuration.  Some  of  these  heuristics  are 
used  in  the  U.S.  Navy’s  SmartNet  Scheduler  [Ref.  14]. 

In  a  standard  ATM  implementation,  the  request  to  establish  a  channel  contains 
a  description  of  the  requirements,  which  includes  the  requested  Quality  of  Service 
(QOS)  and  the  Peak  Cell  Rate  (PCR).  As  the  setup  request  travels  through  the  net¬ 
work,  resources  are  allocated  to  support  the  virtual  channel.  Normally,  these  virtual 
channels  are  created  as  needed  and  then  destroyed  after  the  data  transmission  com¬ 
pletes.  This  coordination  requires  duplex  communication  between  the  sender  and  the 
receiver. 

Within  the  BADD  architecture,  the  CBS  satellite  link  provides  only  simplex 
data  communication  between  the  IDS  and  WFA  ground  stations.  The  BADD  archi¬ 
tecture  therefore  relies  on  static  virtual  channels.  A  static  number  of  virtual  channels 
are  defined  at  the  uplink  and  downlink  ATM  switches  and  these  channels  are  static¬ 
ally  allocated  a  particular  bandwidth  as  well  as  other  attributes,  such  as  guaranteed 
latencies.  Future  implementations  could  define  1024  static  virtual  channels  within  the 
BADD  ATM  network  [Ref.  15]. 

With  static  channels  defined,  BADD  must  employ  some  form  of  scheduling  to 
assign  a  transmission  request  to  a  specific  channel.  This  chapter  reviews  the  basic 
scheduling  problem  and  possible  solutions. 
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B.  SCHEDULING  PROBLEM 

The  problem  of  determining  the  schedule  that  optimizes  throughput  for  execut¬ 
ing  a  set  of  heterogeneous  tasks  using  a  fixed  set  of  heterogeneous  resources  is  one  of 
the  most  difficult  and  challenging  problems  in  computer  science.  This  general  hetero¬ 
geneous  scheduling  problem  and  other  difficult  problems  comprise  a  set  of  problems 
known  as  NP-Complete  problems.  Most  theoretical  computer  scientists  believe  the 
NP-Complete  set  of  problems  are  intractable  [Ref.  16].  For  such  problems,  heuristics 
with  polynomial  runtimes  axe  applied  to  attempt  to  obtain  a  near-optimal  solution. 

In  the  next  sections  we  will  examine  some  heuristic-based  scheduling  algorithms 
we  considered  implementing  in  BADD.  We  provide  the  psuedo-code  for  each  al¬ 
gorithm,  an  example  of  its  execution  to  enhance  understanding,  and  a  discussion 
of  its  strengths  and  weaknesses. 

C.  HEURISTIC  ALGORITHMS 

In  this  section  we  describe  some  heuristic  algorithms  and  explain  both  their 
advantages  and  disadvantages  when  applied  to  the  general  heterogeneous  scheduling 
problem.  Throughout  the  section  we  use  the  term  call  when  addressing  a  pending 
request  for  a  virtual  channel.  We  use  this  term  to  remain  consistent  with  the  termino¬ 
logy  that  is  used  when  we  describe  the  code  for  our  OPNET  implementation  of  BADD. 
In  ATM  terminology,  a  call  refers  to  a  session  between  a  source  and  a  destination.  A 
call  can  contain  one  or  many  messages  inside  it.  A  message  is  defined  as  a  group  of 
packets  that  belong  to  one  specific  communication  application  (i.e.,  an  email  message 
or  a  database  view).  For  this  thesis,  we  assume  that  a  call  contains  only  one  message. 

1.  First  In  First  Out 

The  First  In  First  Out  (FIFO)  algorithm  is  the  simplest  algorithm.  It  assumes 
that  every  channel  can  be  used  for  every  transmission.  The  scheduler  enqueues  all 
pending  calls  onto  a  wait  queue  and  schedules  the  call  at  the  head  of  the  queue  on  the 
next  available  channel. 
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a.  FIFO  Algorithm  Specification 

The  following  is  a  general  algorithm  for  simulating  FIFO  Scheduling. 
This  algorithm  can  be  modified  if  some  calls  are  not  suited  to  some  channels. 

1.  Place  all  jobs  to  be  scheduled  in  the  time-ordered  queue, 
Job_Queue,  and  set  channel_avail_time[channel_number]  =  0  for  all 
channels 

2.  While  (Call_Queue  not  empty) 

3.  Remove  first  call  in  the  Call_Queue. 

4.  Compute  earliest  time  at  which  a  channel  will  finish 
sending  its  current  call.  Store  the  index  of  that  channel 
in  schedule. index. 

5.  Schedule  call  that  was  removed  from  Call.Queue  for 
channel [schedule.index] . 

6.  Update  chainnel.avail.time  [schedule. index]  by  adding  to 
it  the  amount  of  time  needed  to  complete  the  removed 
call. 

7.  End  While 

b.  Examples 

Figure  15  shows  an  example  of  the  steps  for  the  simulation  of  the  FIFO 
algorithm.  There  axe  three  VCs,  and  currently  there  are  three  pending  calls.  In 
step  (a),  the  call  scheduling  matrix  is  created,  which  contains  the  required  time  to 
complete  each  call  when  scheduled  on  each  of  the  virtual  channels  (VC).  We  depict 
the  completion  times  for  previously  scheduled  calls  on  each  of  the  virtual  channels 
using  a  timeline.  In  this  example,  virtual  channels  1  through  3  will  finish  at  times  11, 
15,  and  60,  respectively.  In  step  (b),  we  select  VCl  to  service  call  1  because  it  will 
be  available  at  the  earliest  time,  f  =  11.  (Notice  that  the  values  calculated  in  the  call 
scheduling  matrix  are  not  used  when  selecting  a  channel.  The  matrix  is  only  used 
to  update  the  timeline  values.)  Next  we  increment  the  timeline  to  reflect  that  call  1 
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has  been  scheduled  on  VCl.  In  step(c),  we  repeat  the  actions  of  step  (b)  with  call 
2  and  select  VC2  and  again  update  the  timeline.  Step  (d)  finishes  the  scheduling  by 
scheduling  call  3  on  VC2  and  finalizes  the  timeline  for  this  example. 


VCl  VC2  VC3 

CALLl 
(a.)  CALL  2 
CALLS 

INITIAL  VALUES  FOR  DURATION  OF 
CALL  ON  EACH  OF  THE  VCs 

CALLl 

(b.)  CALL  2 
CALLS 

MATRIX  AFTER  SCHEDULING  CALL  1  ON  VC  I 


VCl  VC2  VC3 


CALL  2 
CALLS 


VCl  VC2  VCS 


100  N 

•  10 

so 

10 

100 

15 

MATRIX  AFTER  SCHEDULING  CALL  2  ON  VC  2 


0  20  40  60  80  100  120 


UPDATED  TIMELINE  AFTER  SCEDULING  CALL  2 


(d.)  CALLS 

MATRIX  / 

Figure  15.  FIFO  Algorithm  Example 
c.  Strengths /Weaknesses 

The  strength  of  the  FIFO  algorithm  is  that  it  is  very  easy  to  implement. 
Its  computational  expense  is  0(n),  where  n  is  the  number  of  calls  requiring  service. 
The  weakness  of  FIFO  is  that  you  may  place  calls  on  channels  that  are  ill  suited  to 
carry  them.  The  scheduling  of  call  3  on  VC2  is  an  example  of  this  problem.  This 
selection  would  require  100  time  units  to  complete.  Selecting  either  of  the  other  virtual 
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channels  would  cause  an  earlier  overall  completion  time  for  all  of  the  calls. 

2.  Best  Fit 

The  Best  Fit  Algorithm  is  also  a  simple  algorithm.  Unlike  the  FIFO  al¬ 
gorithm,  this  algorithm  does  not  ignore  the  criteria  that  the  user  wants  to  optimize. 
In  our  scheduling  problem,  we  attempt  to  minimize  the  time  of  which  the  last  call 
completes.  In  the  following  example,  the  calls  are  scheduled  in  the  order  in  which 
they  are  generated.  For  each  call,  the  channel  that  would  yield  the  minimum  duration 
time,  neglecting  calls  already  scheduled  or  in  progress,  is  scheduled  to  carry  that  call. 

a.  Best  Fit  Algorithm  Specification 

The  following  is  a  general  algorithm  for  implementing  the  Best  Fit  Al¬ 
gorithm. 

1.  Place  all  calls  to  be  scheduled  in  the  time-ordered  queue, 
Call_Queue,  and  set  chcainel_avail_timeCchannel_number]  =  0  for  all 
channels 

2.  While  (Call_Queue  not  empty) 

3.  Remove  first  call  in  the  queue. 

4.  Ignoring  calls  already  in  progress  and  those  already 
scheduled,  compute  fastest  time  in  which  a  channel  can  send 
this  call.  Store  index  of  that  channel  in  schedule_index. 

5.  Schedule  call  that  was  removed  from  Call_Queue  for 
channel [schedule_index] . 

6.  Update  channel_avail_time[schedule_index]  by  adding  to 
it  the  amount  of  time  needed  to  complete  the  removed 
call . 

7.  End  While 

b.  Examples 

Figure  16  displays  an  example  of  the  steps  for  the  execution  of  the  Best 
Fit  Algorithm.  In  step  (a),  each  element  of  the  matrix  contains  the  required  time 
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to  send  the  call  when  scheduled  on  each  of  the  virtual  channels  (VC).  We  depict  the 
completion  times  for  previously  scheduled  calls  on  each  of  the  virtual  channels  using 
a  timeline.  In  this  example,  virtual  channels  1  through  3  will  again  finish  at  times  11, 
15,  and  60,  respectively.  In  step  (b),  for  call  1,  we  select  the  virtual  channel  with  the 
smallest  duration  time.  In  this  example  it  is  VC3.  Next  we  update  the  timeline  and 
remove  call  1  from  the  call  scheduling  matrix.  In  step  (c),  we  repeat  the  actions  of  step 
(b)  with  call  2,  select  VC2,  and  update  the  timeline.  Step  (d)  finishes  the  scheduling 
by  choosing  to  place  call  3  on  VC3  and  finalizing  the  timeline  for  this  example. 
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Figure  16.  Best  Fit  Algorithm  Example 
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c.  Strengths /Weaknesses 

The  strength  of  this  scheduling  algorithm  is  that  it  considers  the  schedul¬ 
ing  criteria.  The  algorithm  is  still  relatively  simple,  requiring  only  a  little  computa¬ 
tional  overhead,  however,  it  is  more  complex  than  FIFO,  being  0{nm)  where  n  is  the 
number  of  calls  and  m  is  the  number  of  channels.  The  major  weakness  is  that  the 
algorithm  does  not  consider  the  load  that  has  already  been  placed  on  each  channel. 
We  see  this  condition  in  the  example  with  the  scheduling  of  call  3  onto  VC3  when  the 
better  choice  would  have  been  to  schedule  it  on  VC  1. 

3.  0{nm)  Greedy  Algorithm 

The  0{nm)  algorithm  is  a  simple,  yet  very  powerful  means  of  scheduling  calls 
onto  virtual  channels.  The  letter  n  again  represents  the  number  of  calls  and  the 
letter  m  represents  the  number  of  virtual  channels.  This  algorithm  considers  both  the 
innate  ability  of  a  channel  to  support  a  transmission  as  well  as  the  current  load  on 
each  channel. 

In  the  0{nm)  Greedy  example  that  follows,  the  scheduling  criteria  is  again 
defined  as  minimizing  the  time  at  which  the  last  virtual  channel  completes.  This 
algorithm  is  different  from  the  previous  scheduling  algorithms  because  it  bases  its 
decision  partly  on  completion  time  of  each  virtual  channel. 

a.  0{nm)  Greedy  Algorithm  Specification 
The  following  is  a  general  algorithm  for  implementing  the  0{nm)  greedy 
algorithm  for  scheduling  calls  onto  static  virtual  channels. 

1.  Place  all  calls  to  be  scheduled  in  the  time-ordered  queue, 
Call_Queue,  and  set  channel_avail_time[channel_number]  =  0 
for  all  channels. 

2.  While  (Call_Queue  not  empty) 

3.  Remove  first  call  in  the  queue. 

4.  Compute  time  at  which  this  call  would  complete  if  assigned 
to  each  channel.  Determine  the  minimum  of  these  completion 
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times.  Store  the  index  of  the  channel  that  yields  the 
earliest  completion  time  in  schedule_index. 

5.  Schedule  the  call  that  was  removed  from  Call.Queue  for 
channel [schedule_index] . 

6.  Update  channel_avail_time[schedule_index] . 

7.  End  While 

h.  Examples 

Figure  17  displays  an  example  of  the  steps  for  the  execution  of  the 
0{nm)  Greedy  Algorithm.  In  step  (a),  the  elements  of  the  matrix  contain  the  required 
time  to  send  a  call  when  scheduled  on  each  of  the  virtual  channels  (VC).  We  depict  the 
completion  times  for  previously  scheduled  calls  on  each  of  the  virtual  channels  using 
a  timeline.  In  this  example,  virtual  channels  1  through  3  will  finish  at  times  11,  15, 
and  60,  respectively.  In  step  (b),  we  add  the  runtime  from  the  matrix  to  the  VC  finish 
time  on  the  timeline  for  the  first  call  only.  We  also  add  these  values  to  the  first  row 
because  the  0(nm)  Greedy  Algorithm  schedules  the  call  with  the  earliest  completion 
time,  then  moves  on  to  schedule  later  calls.  We  also  find  that  VCl  is  the  best  choice 
because  it  has  the  earliest  completion  time,  t  =  36,  so  we  update  the  timeline  to  reflect 
this  choice.  In  step  (c),  we  repeat  the  actions  of  step  (b)  with  call  2  and  select  VC2 
and  update  the  timeline.  Step  (d)  finishes  the  scheduling  by  selecting  call  3  to  be  sent 
on  VCl  and  finalizes  the  timeline  for  this  example. 

c.  Strengths /Weaknesses 

The  strength  of  the  algorithm  is  that  it  requires  relatively  little  overhead 
and  executes  rapidly.  This  greedy  algorithm  is  computationally  the  same  as  the  Best 
Fit  Algorithm  but  is  more  computationally  expensive  than  the  FIFO  example,  0{nm) 
vs.  0{n)  respectively.  This  algorithm  looks  at  the  ramifications  of  scheduling  each 
call  on  all  of  the  available  channels.  It  is  a  good  algorithm  for  the  user  looking  for 
modest  levels  of  improvement  with  little  processing  expense. 
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Figure  17.  0(nm)  Greedy  Algorithm  Example 

4.  An  0(n^77i)  Greedy  Algorithm 

This  Greedy  algorithm  is  more  complex  than  the  0{nm)  greedy  algorithm.  It 
requires  an  evciluation  of  predicted  completion  times  for  all  calls  in  the  scheduling 
matrix,  and  it  generally  produces  better  schedules  at  the  expense  of  more  overhead 
computation. 

a.  Oiri^m)  Greedy  Algorithm  Specification 
The  following  is  a  general  algorithm  for  implementing  the  O(n^m)  greedy 
algorithm  for  scheduling  virtual  channels. 


1.  Place  all  calls  to  be  scheduled  in  the  time-ordered  queue. 
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Call_Queue,  and  set  channel_avail_time[channel_number]  =  0 
for  all  channels. 

2.  While  (Call_Queue  not  empty) 

3.  Compute  time  at  which  each  call  would  complete  if  scheduled 
immediately  on  each  channel,  including  the  time  of  any  calls 
previously  scheduled  on  the  channel. 

4.  Determine  the  (call,  channel)  pair  with  the  earliest 
completion  time.  Store  the  index  of  that  channel  in 
schedule. index,  and  the  index  of  the  call  in  call.index. 

5.  Remove  selected  call  from  Call.Queue [call.index] . 

6 .  Schedule  call  that  was  removed  from  Call.Queue  for 
channel [schedule. index] . 

7.  Update  channel.avail.time[schedule.index] . 

8.  End  While 

b.  Examples 

Figure  18  displays  an  example  of  the  steps  for  the  execution  of  the 
0{n^m)  Greedy  Algorithm.  In  step  (a),  the  elements  of  the  matrix  contains  the 
required  time  to  complete  each  call  if  it  is  scheduled  on  each  of  the  virtual  channels 
(VC).  We  depict  the  completion  times  for  previously  scheduled  calls  on  each  of  the 
virtual  channels  in  a  timeline.  In  this  example,  virtual  channels  1  through  3  will  finish 
at  times  11,  15,  and  60,  respectively.  In  step  (b),  we  add  the  runtime  from  the  matrix 
to  the  VC  finish  time  on  the  timeline  for  all  of  the  calls.  This  is  in  contrast  to  the 
0{nm)  Greedy  Algorithm  where  we  only  applied  values  to  the  top  row  of  the  matrix. 
Next  we  iterate  through  each  column  of  each  row  in  the  matrix  to  find  the  smallest 
value  and  flag  it  with  an  arrow.  Then  we  iterate  through  all  these  flagged  values  and 
find  the  smallest  of  these  values  and  flag  it  with  a  second  arrow.  We  find  that  VCl  for 
call  3  is  the  best  choice  because  it  has  the  earliest  completion,  t  =  21,  so  we  update 
the  timeline  to  reflect  this  choice.  Finally,  we  delete  call  3  from  the  matrix.  In  step 
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(c),  we  repeat  the  actions  of  step  (b)  by  scheduling  call  2  on  VC2  and  updating  the 
timeline.  Step  (d)  completes  the  example  by  scheduling  call  1  on  VCl  and  finalizes 
the  timeline. 
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Figure  18.  0{n^m)  Greedy  Algorithm  Example 


c .  Strengths  /Weakness  es 

The  strength  of  0{n‘^m)  Greedy  Algorithms  resides  in  the  more  ex¬ 
haustive  search  through  the  entire  matrix  to  find  the  minimum  value.  This  schedule  is 
generally  better  than  the  0{nm)  Greedy  Algorithm.  The  disadvantage  of  this  greedy 
algorithm  is  that  it  requires  much  more  computation  to  determine  the  scheduling. 
This  computation  requirement  can  cause  delays  which  the  user  finds  unacceptable. 
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D.  SUMMARY 


In  this  chapter  we  examined  some  of  the  algorithms  available  in  the  SmartNet 
Scheduler  and  provided  examples  to  enhance  the  understanding  of  how  they  work.  We 
also  showed  that  they  could  be  applied  to  scheduling  calls  on  virtual  channels,  whereas 
SmartNet  applies  them  only  to  scheduling  jobs  on  high  performance  machines.  We 
will  use  two  of  the  algorithms  in  our  simulations  for  this  thesis.  The  are  the  FIFO  and 
the  0{n^m)  greedy  algorithms.  The  FIFO  algorithm  is  the  default  used  by  OPNET 
and  we  selected  the  O(n^m)  algorithm  because  it  requires  polynomial  amount  of 
computational  overhead  and  considers  both  channel  loads  and  characteristics.  The 
comparisons  of  these  two  extremes  will  allow  us  to  determine  whether  intelligent 
scheduling  is  worth  the  computational  expense.  In  the  next  chapter,  we  describe  our 
implementation  of  the  BADD  network  using  OPNET. 
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V.  OPNET 


A.  CHAPTER  OVERVIEW 

This  chapter  describes  Optimized  Network  Engineering  Tools  (OPNET) 
from  MIL  3  in  enough  detail  to  allow  the  reader  to  understand  how  we  use  this  state-of- 
the-art  network  modeling  tool  to  model  the  BADD  network.  The  reader  who  is  already 
familiar  with  OPNET  can  safely  skip  this  chapter.  Before  describing  OPNET’s  cap¬ 
abilities,  we  provide  a  quick  overview  of  discrete  event  simulation.  Readers  familiar 
with  this  topic  may  proceed  to  the  following  section. 

B.  DISCRETE  EVENT  SIMULATION 

Why  are  we  using  OPNET?  What  is  Discrete  Event  Simulation?  These  are 
two  excellent  questions.  The  use  of  models  in  simulations  provides  a  means  of  gaining 
understanding  of  complex  problems.  To  construct  the  models  requires  the  modeler  to 
make  simplifying  assumptions  in  order  to  reduce  the  complexity  and  size  of  the  object 
they  wish  to  model  while  preserving  the  most  important  characteristics  of  the  model. 
Models  of  physical  objects,  such  as  bridges,  have  been  used  to  gain  greater  knowledge 
of  the  stresses  associated  with  particular  structures  and  materials.  Some  of  the  same 
modeling  principles  used  with  bridges  can  be  applied  to  a  communication  network 
to  gain  an  understanding  of  that  network’s  dynamic  behavior.  The  term  dynamic 
means  that  the  state  of  the  network  changes  over  time.  As  an  example,  changes  occur 
to  a  network  state  when  a  new  communication  is  placed  on  it  or  when  an  existing 
communication  completes.  One  way  to  capture  the  dynamic  nature  of  the  network  is 
to  use  a  modeling  tool,  such  as  OPNET,  that  supports  Discrete  Event  Simulation. 

To  imderstand  discrete  event  simulation,  the  concept  of  a  state  must  first  be 
defined.  A  state  is  a  collection  of  variables  necessary  to  describe  a  system  at  a 
particular  point  in  time.  The  “number  of  calls”  in  a  wait  queue  is  an  example  of  a 
state  variable  for  a  communication  network.  In  discrete  event  simulations,  the  state 
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variable’s  values  change  instantaneously  at  distinct  points  in  time.  Discrete  event 
simulations  are  useful  for  characterizing  networks  because  the  number  of  calls  in  a 
system  changes  at  discrete  times  when  a  call  arrives  or  when  a  call  is  serviced  by  the 
network.  The  user  is  only  interested  in  these  specific  points  in  time  which  are  called 
events(because  the  state  of  network  does  not  change  continuously).  Discrete  event 
simulations  use  an  event  list  to  chronologically  record  when  generated  events  are  to 
take  place.  The  time  when  state  changes  occur  are  maintained  with  a  simulation 
clock.  By  advancing  the  simulation  clock  only  when  all  scheduled  events  for  a  time 
take  place,  discrete  event  simulations  can  support  the  execution  of  concurrent  events 
in  the  simulation.  The  ability  to  execute  multiple  events  at  the  same  time  is  a  highly 
desirable  feature  because  it  allows  the  user  to  design  more  realistic  simulations. 

Figure  19  depicts  the  flow  of  control  through  the  execution  of  a  discrete  event 
simulation.  At  time  t  =  0,  the  main  program  calls  the  initialization  routine  that  sets  the 
simulation  clock,  initializes  system  states,  initializes  the  empty  event  list,  generates  the 
first  event,  and  places  it  in  the  list.  After  the  initialization  routine  is  complete,  the  main 
program  invokes  a  Simulation  Kernel  that  takes  the  first  event  off  the  time-ordered 
list,  advances  the  clock  to  the  time  of  this  removed  event,  and  invokes  the  Event 
Handler  corresponding  to  this  event.  As  an  event  handler  executes,  it  generates  new 
events  and  places  those  in  the  event  queue.  Also,  during  the  execution  of  an  event 
handler,  the  system  state  is  updated  and  statistical  counters  are  maintained.  When 
an  event  handler  completes,  control  is  returned  to  the  simulation  kernel.  A  program 
implements  simulation  termination  in  any  of  three  ways:  (i)  when  the  simulated  time 
reaches  a  certain  value,  (ii)  when  a  statistical  counter  reaches  a  particular  value,  or  (iii) 
in  unusual  circumstances,  when  the  event  list  is  empty.  When  a  simulation  completes, 
it  computes  the  statistics  of  interest  and  writes  a  report  for  analysis.  We  presented  a 
very  high  level  view  of  discrete  event  simulations  and  the  interested  reader  can  consult 
textbooks  for  a  more  detailed  discussion  of  this  topic.  [Ref.  17] 
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Figure  19.  Discrete  Event  Simulation  Flow  Control  (From  [Ref.  17]). 
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C.  QPNET  OVERVIEW 

OPNET  is  a  robust  and  comprehensive  engineering  system  capable  of  simulat¬ 
ing  large  communication  networks  with  detailed  protocol  modeling  and  performance 
analysis.  OPNET  is  an  object-oriented  modeling  system  that  allows  the  User  to  easily 
traverse  through  a  multi-level  network  model  to  perform  refinements  and  modifica¬ 
tions  in  support  of  an  iterative  design  approach  [Ref.  4].  Figure  20  shows  OPNET’s 
Hierarchy  where  the  Network  Layer  is  built  from  Sub-Networks,  Sub-Networks 
are  built  from  Nodes,  and  the  Nodes  are  built  from  Process  Models. 


The  Network  Layer  through  the  Node  Layer  focus  on  the  topography  of  the 
network.  This  allows  the  user  to  visualize  the  structure  and  interactions  between 
objects  in  the  network  at  finer  levels  of  abstraction  as  we  move  down  through  the 
layers.  While  the  Network  Layer  in  our  example  only  shows  a  geographic  relationship 
of  the  network  between  Flagstaff  and  Boston,  the  Node  module  provides  much  greater 
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detail  by  indicating  the  functionality  of  the  node  by  using  a  naming  convention  (i.e., 
the  server  node  with  the  name  S6). 

The  Process  Model  defines  the  behavior  for  processors  and  queue  modules  in 
OPNET.  A  process  is  an  instance  of  a  process  model  and  operates  within  an  OPNET 
processor  module.  In  Figure  20,  we  show  that  the  server  processor  module  has  various 
states  within  its  process  model  (init,  wait,  receive,  and  transmit).  These  states,  and 
the  transitions  between  them,  reflect  the  specific  behaviors  that  occur  repeatedly  in  a 
server.  Now  that  the  reader  has  a  general  understanding  of  the  hierarchical  framework, 
we  describe  how  OPNET  supports  discrete  event  simulation. 

D.  OPNET  SUPPORT  OF  DISCRETE  EVENT  SIMULA¬ 
TION 

OPNET  supports  discrete  event  simulation  of  network  loads,  allowing  the  user 
to  easily  modify  attributes  and  providing  analysis  tools  with  which  to  examine  network 
performance,  either  globally  or  at  at  specific  points  in  a  network.  OPNET  uses  a 
Simulation  Kernel  to  rim  the  simulation  by  controlling  the  addition  and  deletion  of 
events  to  a  single  event  list.  The  simulation  kernel  and  process  models  can  generate 
events  for  addition  to  the  event  list  using  OPNET  Kernel  Procedures  (KPs). 
KPs  also  allow  the  user  to  gain  information  about  the  event  list,  for  example,  the 
time  of  the  next  scheduled  event.  Events  can  be  added  to  the  event  list  for  the  current 
simulation  time  or  for  any  time  in  the  future.  (Events  from  the  past  cannot  be  added  to 
the  list.)  Figure  21  illustrates  an  OPNET  event  list.  The  boxes  in  the  figure  represent 
events  scheduled  on  the  list.  We  have  highlighted  OPNET’s  ability  to  support  multiple 
events  on  the  list  which  axe  to  occur  at  the  same  time.  It  accomplishes  concurrent 
execution  by  executing  all  events  scheduled  for  the  same  time  before  advancing  the 
simulation  clock  to  the  time  of  the  next  event  on  the  list.  We  also  highlight  the  fact 
that  the  time  between  events  on  the  list  can  be  variable  which  is  characteristic  of  using 
Next-Event  time  advance  with  simulation  time. 
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Figure  21.  Distribution  of  Events  on  an  Event  List  (From  [Ref.  4]). 


The  user  accesses  the  KPs  within  processes  using  the  Process  Editor.  The 
Process  Editor  will  be  discussed  in  greater  detail  later  in  this  chapter;  however,  we 
will  discuss  its  interaction  with  the  simulation  kernel  now.  As  we  stated  earlier,  the 
simulation  kernel  adds  events  to  the  event  list.  This  is  accomplished  when  the  kernel 
receives  interrupts.  Interrupts  can  come  from  the  kernel  itself  or  from  the  process 
models.  Examples  of  kernel  interrupts  are  those  that  signal  the  beginning  and  ending 
of  the  simulation.  Examples  of  process  models  calling  interrupts  include  one  that 
causes  a  process  to  transition  from  one  state  to  another  after  a  specified  delay,  one 
that  allows  a  process  to  signal  another  to  perform  an  operation,  and  one  that  sends 
a  packet  to  another  process  and  notifies  that  process  when  the  packet  arrives.  For 
example,  the  last  interrupt  described  above  would  be  called  in  the  transmit  state  found 
in  Figure  20.  In  the  following  section  we  will  discuss  the  Process  Editor  in  more  detail, 
describing  how  to  use  it  to  construct  finite  state  machines.  We  now  examine  the  tools 
OPNET  provides  to  build  network  models  and  simulate  network  loading. 


E.  OPNET  TOOLS 

OPNET  supports  network  design,  testing,  and  analysis  with  the  eight  tools 
listed  in  Table  VII.  All  of  OPNET’s  tools  are  available  through  an  advanced  graphical 
user  interface  (GUI)  known  as  the  MIL  3  User  Interface.  It  provides  support 


54 


utilities  in  each  of  the  tools  that  are  accessed  via  action  buttons.  Some  of  these 
utilities  are  common  to  all  of  the  editors,  such  as  the  utilities  that  read  and  write  files 
and  print  reports  and  graphics.  Other  utilities  are  unique  to  a  particular  tool.  We 
will  only  address  the  most  commonly  used  utilities  within  each  of  .  the  tools.  Now  we 
will  describe  the  function  of  each  of  these  tools. 


Tool 

Purpose 

Network  Editor 

Design  Overall  Network  Topology 

Node  Editor 

Design  and  Edit  Nodes  in  Network 

Process  Editor 

Design  and  Modify  State  Diagrams  of  Nodes 

Parameter  Editor 

Modify  Parameters  of  Links  and  Packets 

Probe  Editor 

Set  Probes  to  Collect  Network  Statistics 

Simulation  Tool 

Configure  and  Run  Simulations  on  Network 

Analysis  Tool 

Evaluate  Data  Collected  during  Simulation 

Filter  Editor 

Define  numerical  processing  filters  to 
take  multiple  inputs  and  produce  an  output 

Table  VII.  OPNET  Tools  (Derived  From  [Ref.  4]). 


1.  The  Network  Editor 

The  Network  Editor  is  used  to  construct  the  user’s  network  models.  Its  main 
purpose  is  to  define,  at  a  high  level,  the  topology  of  the  network.  Networks  in  OPNET 
consist  of  communication  nodes  connected  by  point-to-point  links,  busses,  and  radio 
links.  The  nodes  and  links  can  be  grouped  together  to  form  subnetworks.  These 
subnetworks  can  then  be  viewed  as  single  objects  within  a  larger  network,  rendering 
simpler  models  that  are  more  easily  understood. 

The  most  commonly  used  utility  in  the  Network  Editor  is  an  Object  Palette. 
It  allows  the  user  to  configure  a  workspace  to  contain  only  those  objects  that  are 
necessary  for  the  network  currently  under  development.  For  example,  when  designing 
an  ATM  network,  there  is  no  need  for  models  supporting  Ethernet.  This  utility  also 
includes  a  Rapid  Configuration  constructor  to  allow  the  user  to  quickly  build  the 
most  common  networks  such  as  a  star  or  bus  topology.  Also  useful  is  the  Carto- 
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graphic  Background  that  allows  the  user  to  load  maps  as  a  background  for  their 
networks. 


Figure  22  displays  the  Network  Editor,  with  the  Object  Palette  open,  and  an 
example  network  model. 


Figure  22.  OPNET  Network  Editor.  From  [Ref.  7] 


2.  Node  Editor 

The  Node  Editor  is  used  to  construct  models  of  nodes  within  the  network.  It 
provides  magnification  to  the  network  model,  showing  more  details  of  the  network 
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topology  at  a  local  level.  Nodes  are  created  by  connecting  modules  (i.e.,  processors, 
queues,  data  generators,  receivers  and  transmitters)  together  with  packet  streams 
and  statistic  wires.  Packet  streams  allow  packets  to  be  sent  between  the  output 
interface  of  a  source  module  and  the  input  interface  of  the  destination  module.  Statistic 
wires  support  the  flow  of  numerical  data  by  connecting  output  statistics  of  a  source 
module  to  the  input  statistic  of  the  destination  module.  The  most  commonly  used 
utilities  are  listed  in  Table  VIII. 


Action  Button 

Purpose 

Processor 

General  purpose,  programmable  object, 
whose  behavior  is  specified  by  Process  Modules 

Ideal  Generator 

Used  to  generate  random  packets 

Clock  Generator 

Used  to  generate  packets  aligned  with  a 
synchronous  clock 

Queue 

Used  to  queue  up  packets  awaiting  service 

Pt-Pt/Bus  Receiver 

Used  to  receive  packets 

Pt-Pt/Bus  Transmitter 

Used  to  transmit  packets 

Table  VIII.  OPNET  Node  Editor  Action  Buttons  (Derived  From  [Ref.  4]). 


The  Node  Editor  allows  the  user  to  create  and  assign  specific  naming  attributes 
to  the  modules  that  comprise  their  network.  An  example  would  be  assigning  the  name 
“server”  to  a  user  defined  module.  The  construction  of  a  node  provides  a  skeleton  of 
the  modules  required  to  accomplish  its  particular  function  (i.e.  processor,  generator, 
or  queue).  To  fill  in  the  skeleton  we  use  the  finite  state  machines  found  in  the  Process 
Editor. 

3.  Process  Editor 

The  Process  Editor  is  the  most  important  component  of  OPNET.  The  Process 
Editor  allows  the  user  to  create  state  diagrams  for  the  processor  and  queue  modules 
defined  in  their  Nodes.  State  diagrams  are  useful  when  modeling  networks  because 
of  the  nature  of  networks.  Networks  are  dynamic,  and  transition  between  a  finite 
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number  of  well-defined  states  (i.e.  idle,  transmitting  data,  receiving  data).  Networks 
do  not  create  new  states  over  time.  They  rotate  between  a  finite  number  of  states 
based  on  responses  to  specific  stimuli.  State  diagrams  allow  the  user  to  abstract  these 
states,  and  the  transitions  that  cause  them  to  move  between  states,  into  a  form  that  is 
easily  understood.  In  addition,  state  diagrams  are  easily  integrated  into  discrete  event 
simulations  because  the  states  of  a  process  model  can  easily  be  correlated  to  events 
in  a  simulation.  A  more  detailed  explanation  of  state  diagrams  is  found  in  Hopcroft 
and  Ullman’s  book  [Ref.  18]. 

Process  Models  represent  the  logic  embodied  in  the  communications,  hard¬ 
ware,  network  protocols,  and  algorithms  that  comprise  the  network.  It  is  important 
to  note  that  Process  Models  define  the  states  of  processors  and  that  these  two  terms 
are  not  interchangeable.  To  use  an  analogy,  the  Nodes  in  a  network  are  similar  to  the 
skeletal  structure  of  a  human.  The  process  models  of  a  network  provide  movement 
in  the  network  states  just  as  the  muscles  and  tendons  that  attach  to  the  bones  on  the 
skeleton  make  movement  possible  in  a  hiunan.  A  processor  is  similar  to  the  shell  of 
an  non-descript  muscle.  It  requires  further  behavioral  definition,  through  the  use  of 
state  diagrams,  to  describe  its  specific  function. 

The  Process  Editor  uses  Proto-C,  a  language  that  combines  graphical  state 
transition  diagrams,  embedded  C  language  data  items  and  statements,  and  a  library 
of  kernel  procedures  to  provide  commonly  needed  functionality  for  modeling  commu¬ 
nication  networks  and  information  processing  systems.  The  process  editor  allows  the 
user  to  view  this  code  using  the  action  buttons  listed  in  Table  IX. 

Figure  23  displays  the  Process  Editor  with  a  state  diagram  as  a  traffic  gen¬ 
eration  module.  OPNET  state  transition  diagrams  are  composed  of  both  state  and 
transition  components.  In  the  next  portion  of  this  section  we  will  describe  the  attrib¬ 
utes  of  these  components  that  allow  the  user  to  define  protocols  in  support  of  discrete 
event  simulations. 

States  may  have  associated  with  them  actions  to  be  executed  upon  entry  into 
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Action  Button 

Purpose 

Edit  State 
Variables 

Allows  declaration  and  modification  of  state 
variables  that  represent  persistent  counters,  routing 
tables,  etc.  State  variables  can  only  be  modified  by 
explicit  assignment  statements  by  the  process  itself. 

Edit  Temp 
Variables 

Allows  declaration  and  modification  of  temporary 
variables  used  for  “scratch”  storage 
in  calculations  (non-persistent). 

Edit  Header 
Block 

Allows  declaration  and  modification  of  global 
variables..  Global  variables  allow  multiple  processes  to 
access  them  creating  dependencies  among  processes 

Edit  Function 
Block 

Allows  editing  and  declaration  of  functions  that  support 
recurring  calculations 

Edit  Diagnostic 
Block 

Used  to  indicate  which  state  variables  should  be 
monitored.  Used  for  debugging. 

Table  IX.  OPNET  Process  Editor  Action  Buttons  (Derived  From  [Ref.  4]). 

the  state,  (called  enter  executives),  and  when  exiting  the  state,  (called  exit  ex¬ 
ecutives).  Calls  to  OPNET  defined  functions,  or  C-code  written  by  the  user,  cause 
the  execution  of  these  actions. 

OPNET  classifies  states  in  a  process  model  to  be  either  forced  or  unforced. 
Unforced  states  allow  a  pause  in  execution  between  the  enter  executives  and  the  exit 
executives.  In  other  words,  once  the  enter  executives  of  an  unforced  state  are  com¬ 
pleted,  the  simulation  kernel  can  take  control  and  execute  another  event.  While  an¬ 
other  event  is  being  processed  for  another  process,  this  process  remains  in  the  unforced 
state.  Eventually  the  simulation  kernel  will  regain  control  again  and  signal  the  process 
to  execute  its  corresponding  exit  executives.  Forced  states  do  not  permit  the  simula¬ 
tion  kernel  to  execute  between  the  enter  and  exit  executives.  Since  forced  states  do 
not  relinquish  control  to  the  simulation  kernel,  OPNET  requires  every  process  to  have 
at  least  one  unforced  state. 

Transition  for  OPNET  are  classified  either  as  conditional  or  non-conditional. 
Conditional  transitions  occur  when  a  condition  is  placed  on  a  transition,  such  as  the 
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Figure  23.  OPNET  Process  Editor.  From  [Ref.  4] 


CALL-START  condition  between  the  IDLE  and  START  states  in  Figure  23.  In 
this  example,  a  call-start  signal  must  be  received  for  the  transition  to  occur.  The 
transition  between  the  INIT  and  the  CONFIG  states  in  the  same  figure  depicts  a 
non-conditional  transition.  OPNET  uses  dashed  arcs  to  depict  conditional  transitions 
and  solid  arcs  to  depict  non-conditional  transitions. 

In  order  to  support  concurrent  operations  in  a  simulation,  OPNET  allows 
processes  to  spawn  new  processes,  called  dynamic  processes.  There  is  no  constraint 
on  the  number  of  dynamic  process  spawned  in  support  of  a  simulation.  In  the  next 


chapter  we  will  discuss  in  detail  the  use  of  dynamic  processes  to  support  our  model 
of  the  BADD  Network. 

4.  Parameter  Editor 

The  OPNET  Parameter  Editor  provides  easy  access  to  several  other  tools  that 
can  be  used  to  edit  complex  objects.  Some  examples  of  these  complex  objects  include 
the  Packet  Formats  shown  in  Figure  24,  the  Interface  Control  Information  Format 
(ICI)  shown  in  Figure  25,  and  the  Link  Model  shown  in  Figure  26. 


I  OPNET  Modeler  3.0.  A  (c)  1996  MIL  3,  Inc.  Farmeter  Editor:  ams_atin__cdl 


Figure  24.  OPNET  Packet  Format  (From  [Ref.  4]). 


I  OPNET  Modeler  3.0.A  (c)  1996  MIL  3,  Inc.  IOmeter  Editor:  badd  call  req_if  id 


Figure  25.  OPNET  Interface  Control  Information  Format  (From  [Ref.  4]). 

5.  Probe  Editor 

The  Probe  Editor  is  used  to  specify  locations  where  the  user  would  like  to 
collect  data.  Probes  are  specified  prior  to  running  a  simulation.  Several  types  of 
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Figure  26.  OPNET  Link  Format  (From  [Ref.  4]). 
probes  and  their  functions  are  listed  in  Table  X. 


Action  Button 

Purpose 

Node 

Statistic 

Supports  collection  of  built-in 
and  user-defined  statistics 

Link 

Statistic 

Supports  collection  of  built-in  statistics 
on  link  objects  at  the  network  level 

Global 

Statistic 

Supports  collection  of  values  from 
multiple  objects  throughout  the  network 

Simulation 

Attribute 

Records  scalar  statistics  for  post-simulation 
analysis  of  simulation  outputs 

Automatic 

Animation 

Provides  programming-free  animation 
of  packet  flows  at  network  and 
node  level;  node  movement  at  network 
level;  and  state  transitions  of  a  process 

Custom 

Animation 

Provides  custom  animation  within  process 
models  and  link  models  (requires  user 
programming) 

Statistic 

Animation 

Provides  programming-free  animation  depicting 
statistics  through  the  simulation 

Table  X.  OPNET  Probe  Editor  Action  Buttons  (Derived  From  [Ref.  4]). 

6.  Simulation  Tool 

OP.NET  provides  a  user-friendly  graphical  interface  with  which  the  user  can 
run  multiple  simulations  simultaneously.  OPNET  also  allows  the  user  to  run  simu- 
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lations  from  the  command  line.  Running  simulations  from  the  command  line  can  be 
useful  for  saving  simulation  rims  and  traces  into  files  for  later  analysis.  The  com¬ 
mand  line  interface  also  provides  a  number  of  standard  fields  that  support  unattended 
execution  of  simulations.  These  fields  are  summarized  in  Table  XL 


Field 

Purpose 

Network 

Network  Model  used  for  simulation 

Probe  File 

Name  of  Probe  File  specifying  data  collected 
during  the  simulation 

Vector  File 

Name  of  file  to  store  vector 
output  generated  by  simulation  . 

Scalar  File 

Name  of  file  to  store  scalar 
output  generated  by  simulation 

Seed 

Allows  user  to  vary  seed  to  gain 
statistical  confidence  in  results 

Duration 

Maximum  duration  of  simulation 
in  simulated  seconds 

Application 

Specific 

Allows  user  to  define  values  for  promoted 
attributes  of  network  and  process  models 

Table  XL  OPNET  Simulation  Editor  Fields  (Derived  From  [Ref.  4]). 


7.  Analysis  Tool 

The  Anedysis  Tool  supports  the  display  of  data  stored  in  two  types  of  files,  the 
output  vector  files  and  the  output  scalar  files.  Output  vector  files  are  collections  of 
pairs  of  real  values.  Output  vectors  contain  the  information  from  the  simulation  and 
are  used  as  input  to  construct  traces.  Traces  are  ordered  sets  of  abscissa  and  ordinate 
pairs,  called  entries  (traces  are  similar  in  structure  to  vectors  [Ref.  4j).  OPNET  allows 
the  user  to  view  vector  information  in  panels.  A  panel  is  a  two-dimensional  time-series 
graph  format  with  the  horizontal  axis  value  representing  an  independent  variable, 
usually  simulation  time,  and  the  vertical  axis  representing  a  dependent  variable.  The 
analysis  tool  also  provides  the  ability  to  plot  multiple  traces  on  a  single  panel.  Such 
plots  axe  useful  for  comparing  multiple  different  runs.  Additionally,  this  tool  allows 
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the  user  to  vary  the  scale  and  range  of  the  axes  to  focus  on  specific  segments  of  interest. 
Figure  27  shows  an  example  of  output  from  the  Analysis  Tool. 


Figure  27.  OPNET  Analysis  Tool  (From  [Ref.  4]). 


Output  scalar  files  contain  values  that  are  accrued  over  multiple  simulations. 
Examples  of  values  that  can  be  found  in  these  files  are  average  wait  times,  peak  sizes 
of  queues,  and  standard  deviations  and  means  for  end-to-end  delays. 

8.  Filter  Editor 

The  Filter  Editor  allows  the  user  to  edit  models  that  define  the  mathematical 
processing  of  simulation  results.  A  filter  model  can  be  thought  of  as  a  single  system 
that  defines  both  inputs  and  an  algorithm  for  computing  the  output.  Figure  28  de¬ 
picts  a  schematic  of  an  implementation  of  a  general  filter  editor.  OPNET  supports  a 
hierarchical  structure  of  filtering  where  multiple  computations  are  executed  to  derive 
a  desired  value.  This  desired  value  is  derived  by  linking  the  outputs  from  multiple 
filters  together  using  filter  connections.  The  composition  of  multiple  filters  is  called 
a  macro  filter.  The  editor  also  contains  pre-defined  filters  that  the  users  can  use  to 
build  macro  filters.  These  filters  include  an  Adder,  Gain,  Multiplier,  Mean,  Average, 
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Sum,  Differentiator,  Integrator,  Exponentiator,  Logarithm,  Delay  and  Time  Window 
Filter. 

Generalized  Model  of  a  Filter 


Figure  28.  Generalized  OPNET  Filter  From  [Ref.  4] 


F.  SUMMARY 

OPNET  is  a  sophisticated  network  engineering  tool  as  seen  from  the  review  of 
its  tools  above.  These  tools  provide  us  with  a  framework  for  developing  new  variations 
of  protocols  and  testing  these  variations  with  simulations.  In  the  next  chapter  we 
explain  how  we  used  OPNET  to  model  BADD  and  intelligent  scheduling  of  the  ATM 
virtual  channels  contained  in  the  BADD  network. 
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VI.  DESIGN  OF  BADD  NETWORK  WITHIN 

OPNET 

A.  INTRODUCTION 

The  goal  of  this  work  is  to  design  a  model  of  the  BADD  network  with  OPNET 
in  order  to  simulate  and  evaluate  the  performance  of  different  network  channel  schedul¬ 
ing  algorithms.  This  chapter  describes,  in  detail,  our  OPNET  design  of  the  BADD 
network,  in  particular,  the  design  of  static  channels  within  the  BADD’s  ATM  net¬ 
work,  the  design  and  integration  of  multiple  call  requesters,  and  the  design  of  several 
different  BADD  call  schedulers. 

This  chapter  includes  numerous  diagrams  of  nodes,  modules,  and  processes 
within  OPNET.  The  state  names  in  many  of  the  diagrams  are  truncated  by  OPNET’s 
graphic  print  utility.  The  complete  state  name  is  used  in  our  descriptions  and  all 
OPNET  reports. 

Processes  are  not  included  in  node  diagrams  because  processes  are  dynamic. 
Because  we  do  not  know  the  exact  timing  or  the  exact  number  of  calls  generated  during 
a  given  simulation,  processes  are  created  dynamically  as  needed.  These  dynamic 
processes  allow  concurrent  processing  of  multiple  call  requests. 

As  stated  in  the  Chapter  VI,  OPNET  supports  multiple  events  occurring  in  the 
simulation  at  the  same  time.  OPNET  uses  dynamic  processes  to  support  this  concur¬ 
rency  feature.  The  distinction  between  normal  processes  and  dynamic  processes  can 
best  be  drawn  from  the  following  analogy.  Regular  processes  reflect  the  hardware  in 
a  system,  they  can  only  accomplish  one  action  at  a  time.  Dynamic  processes  reflect 
actions  that  are  running  independently. 

B.  BADD  NETWORK 

Our  first  objective  was  to  use  OPNET  to  design  and  implement  a  model  of 
the  BADD  network.  Because  the  overall  BADD  network  is  extremely  complex,  we 


67 


scaled  our  design  to  focus  on  the  ATM  backbone  between  the  IDS  and  the  WFA.  This 
portion  of  the  network  contains  the  GBS  (satellite)  ATM  link.  As  detailed  in  chapter 
III,  this  link  reduces  the  effective  ATM  network  capacity  to  8  Mbps.  We  will  use  our 
model  to  simulate  various  scheduling  policies  to  determine  which  are  best  at  directing 
the  network  traffic  through  this  bottleneck. 

The  GBS  link  provides  only  simplex  communication.  However,  OPNET  cur¬ 
rently  only  supports  duplex  ATM  channels.  The  subsection  titled  Network  Com¬ 
munication  Links  describes  how  we  modified  OPNET’s  duplex  communications 
links  to  closely  approximate  the  GBS’s  simplex  links.  A  high  level  view  of  our  initial 
BADD  network  model  is  given  in  Figure  29. 

The  initial  BADD  model  was  developed  using  OPNET’s  ATM  modules  inter¬ 
connected  to  reflect  the  BADD  architecture.  OPNET  provides  various  ATM  modules 
to  support  the  standard  ATM  network  protocol.  Because  BADD  utilizes  ATM  in  such 
an  unusual  way,  we  selected  OPNET’s  simplest  ATM  modules  and  modified  them  as 
necessary  to  support  our  model.  A  full  description  of  each  of  the  components  and 
network  modifications  is  given  in  the  remainder  of  this  section. 

In  the  subsections  below  we  will  be  describing  the  various  modules  that  com¬ 
prise  the  four  nodes  in  Figure  29.  Quite  often  a  particular  module  may  be  used  by 
more  than  one  node.  When  we  describe  such  a  module,  we  will  note  which  other 
nodes  it  is  used  in  and  provide  a  general  description  of  its  function  and  structure.  For 
example,  in  describing  the  ATM_mgmt  module  in  the  IDS  LAN  traffic  source  node,  a 
module  that  is  also  present  in  all  of  the  other  nodes,  we  will  say  that  certain  states  may 
be  used  to  decide  whether  the  final  destination  of  a  message  is  that  node  or  another. 

1.  IDS  LAN  Subnet 

As  described  in  chapter  III,  the  IDS  consolidates  information  to  be  broadcast 
over  the  GBS  system.  For  simplicity,  we  first  modeled  the  IDS  LAN  as  a  single  traffic 
source  node.  This  initial  traffic  source  generates  constant  sized  data  packets  at  a 
constant  rate;  a  decision  we  made  to  keep  the  model  simple  until  the  overall  network 
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Figure  29.  Designed  BADD  Network  within  OPNET. 
model  functioned  properly. 

A  detailed  view  of  the  IDS  LAN  node  is  shown  in  Figure  30.  This  node  consists 
of  four  basic  components:  a  module  to  generate  calls,  an  AAL  module,  several  ATM 
modules  and  a  transmitter-receiver  pair. 


receiver  flTM_s«ritoh  transmitter 

Figure  30.  Initial  BADD  traffic  source  node  with  single  call  .generator. 

This  node  communicates  with  other  nodes  in  the  network  through  the  transmitter- 
receiver  pair  (transceiver).  A  transceiver  is  required  for  each  communication  link. 
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a.  The  Call  Generation  Module 

The  function  of  the  call_generator  module  is  to  generate  requests  to  send 
data  as  well  as  to  generate  the  a,ctual  data  packets  to  be  broadcast  over  the  simulated 
BADD  network.  The  state  diagram  illustrating  the  action  of  this  module  is  shown  in 
Figure  31.  A  description  of  these  states  is  given  below. 

(default) 


s  ^ 


Figure  31.  State  diagram  for  initial  BADD  call-generator. 


•  INIT.  When  the  program  is  in  this  state  it  initializes  the  variables  local  to 
this  module.  Using  functions  provided  by  OPNET,  it  also  reads  the  model 
attributes  for  this  module.  The  model  attributes  include  the  mean  duration  of 
the  call,  the  mean  call  wait  time,  the  mean  interarrival  rate  and  the  mean  packet 
size.  These  attributes  define  the  type  of  calls  generated  by  this  module.  The 
use  of  each  of  these  variables  is  described  in  other  states  within  this  module. 

•  config.  From  the  INIT  state,  the  process  transitions  to  the  config  state  where 
it  first  broadcasts  the  IDS  LAN’s  network  management  information,  such  as 
object  ID,  module  ID,  and  module  type,  to  a  corresponding  module  inside  all 
other  nodes.  Then  it  waits  to  receive  their  information.  The  waiting  is  shown  in 
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our  diagram  by  the  transition  labeled  default.  We  note  that  while  the  process 
is  in  this  state,  it  can  be  interrupted  by  the  simulation  kernel.  As  described  in 
Chapter  V,  this  is  called  an  unforced  state. 

•  schedule.  When  the  module  enters  this  state  it  generates  an  event,  in  the 
future,  at  which  time  the  next  request  will  be  generated.  The  time  of  the 
generated  event  is  controlled  by  the  mean  call  wait  time  distribution  read 
while  the  process  was  in  the  INIT  state. 

•  idle.  The  process  remains  in  the  idle  state,  an  unforced  state,  until  the  gen¬ 
erated  request  time  arrives.  This  wait  time  was  determined  in  the  schedule 
state. 

•  start.  When  the  time  arrives  for  the  scheduled  call  to  occur,  this  process 
transitions  to  the  start  state.  The  module  initiates  the  call  by  creating  a  call 
descriptor  Interface  Control  Information  (Ici)  packet  and  forwarding  the 
Ici  to  the  remote  AAL  module.  The  Ici  is  an  OPNET  defined,  multi-member 
data  item  used  to  pass  control  information  between  different  modules  and 
processes.  The  Parameter  Editor,  as  described  in  Chapter  V,  can  be  used  to 
modify  the  Ici  format.  For  this  module,  we  used  the  predefined  Ici,  amsJfJci 
packet.  This  Ici  contains  the  call’s  destination  address,  the  call’s  AAL  type, 
the  call’s  QOS  class,  and  the  call’s  traffic  contract  requirements. 

•  EstCon.  The  module  waits  in  this  state  for  the  AAL  module  to  respond  to 
the  call  request.  If  the  AAL  module  responds  with  a  call  release  indication 
because  the  network  cannot  support  the  call  request,  this  module  drops  the 
call  request  and  transitions  back  to  the  schedule  state.  If  the  AAL  module 
responds  with  a  call  connection  signal,  the  module  generates  a  delayed  event 
that  signifies  the  end  of  the  call.  Rather  than  count  packets,  this  module 
generates  packets  until  the  end  of  the  call  event  arrives.  The  delay  time  for 
this  event  is  generated  using  the  mean  call  duration  described  earlier.  Finally, 
it  generates  an  event  corresponding  to  the  generation  of  the  first  data  packet 
which,  after  an  appropriate  wait  time,  causes  a  transition  to  the  data  gen 
state. 

•  data  gen.  While  in  this  state  the  process  generates  data  packets  and  forwards 
the  data  packets  to  the  AAL  module.  The  data  packets  are  generated  at  the  size 
and  rate  defined  by  the  model  attributes  mean  packet  size  and  mean  interarrival 
time,  respectively.  The  module  remains  in  this  state  until  the  end  of  the  call 
event  arrives  or  the  AAL  module  signals  a  release  of  the  data  channel.  If  the  call 
request  is  completed,  this  state  sends  a  call  release  signal  to  the  AAL  module 
and  transitions  to  the  RelCon  state.  If  the  AAL  module  sent  a  call  release 
signal,  meaning  the  network  dropped  the  channel,  this  state  stops  sending  data 
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packets  and  drops  the  call  request.  The  call  release  signal  causes  a  transition 
back  to  the  schedule  state  for  scheduling  the  next  call. 

•  RelCon.  When  in  this  state,  the  module  waits  for  the  AAL  module  to  signal 
a  Release  Confirm  acknowledgment,  meaning  the  ATM  network  completed  the 
transmission  of  all  data  packets  and  has  released  the  channel  resources.  Upon 
receiving  Release  Confirm,  this  module  transitions  back  to  the  schedule  state. 

b.  AAL  Module 

The  AAL  module  serves  as  the  interface  between  the  calLgenerator 
and  the  ATM  modules.  While  in  this  section  we  focus  our  descriptions  on  the  IDS 
LAN  node,  this  module  is  also  used  in  the  TACTICAL  LAN  node.  This  module 
coordinates  the  signaling  of  call  requests  from  the  calLgenerator  and  it  segments  the 
call  data  packets  into  48-byte  segments  for  transport  across  the  ATM  network.  The 
AAL  process  state  diagram  is  shown  in  Figure  32.  A  description  of  these  states  is 
given  below. 


Figure  32.  State  diagram  for  AAL  module. 


•  INIT.  This  state  is  used  to  initialize  numerous  variables  within  the  process 
model.  Additionally,  while  in  this  state,  the  module  creates  and  initializes 
memory  that  is  shared  with  all  dynamic  processes  spawned  by  this  module. 
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•  dispatch.  In  this  state,  the  module  distributes  appropriately  all  requests  re¬ 
ceived  by  the  AAL  module.  The  distribution  is  controlled  by  the  type  of 
request  received  and  the  data  within  the  request. 

•  notify.  The  process  in  this  state  broadcasts  node  descriptor  information  to  all 
other  nodes  within  the  simulation  network. 

•  setup.  Upon  receipt  of  a  call  request  from  the  call-generator  or  the  network, 
this  state  is  used  to  spawn  a  dynamic  Signaling  AAL  (SAAL)  process  to 
handle  that  request.  It  then  passes  the  call  descriptor  Ici  to  the  newly  created 
process.  Because  the  SAAL  process  is  a  dynamic  process,  it  is  not  shown  in 
Figure  31.  (The  SAAL  process  is  described  later  in  this  section.) 

•  conn  irpt.  When  in  this  state  the  module  receives  and  processes  signals  per¬ 
taining  to  individual  channel  connections.  Based  upon  the  type  of  signal  re¬ 
ceived,  this  module  forwards  the  connection  signal  to  the  corresponding  SAAL 
for  processing.  This  module  then  transitions  back  to  the  dispatch  state. 

c.  ATM-layer  Module 

The  ATM  Jayer  module  is  the  first  of  the  four  ATM  modules  in  OPNET. 
(Together  these  four  ATM  modules  perform  all  of  the  functions  of  the  ATM  layer  as 
defined  in  chapter  II.)  This  module  is  used  in  all  nodes  throughout  the  network.  This 
module  is  responsible  for  coordinating  the  functions  of  the  other  three  ATM  modules. 
Primarily,  it  serves  as  an  interface  between  the  ATM  modules,  AAL  module,  and  the 
application  modules.  It  forwards  call  requests  to  the  ATM_mgmt  module  for  Virtual 
Path  Identifier  (VPI)  and  Virtual  Channel  Identifier  (VCI)  assignment.  It  forwards 
data  cells  to  the  ATMjswitch  module.  The  ATM  Jayer  process  state  diagram  is  shown 
in  Figure  33.  A  description  of  these  states  is  given  below. 

•  INIT.  When  in  this  state,  the  module  initializes  local  variables. 

•  config.  This  state’s  functionality  is  identical  to  the  config  state  in  the  call-generator 
module  on  page  70. 

•  wait.  This  state  waits  for  an  event  (reception  of:  a  call  request,  data  packets 
or  network  messages)  to  occur  and  uses  it  type  to  determine  the  next  state. 

•  AAL  int.  This  state  forwards  the  call  descriptor  Ici  to  the  ATM-mgmt  module 
when  a  call  request  is  received  from  the  AAL  module. 
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Figure  33.  State  diagram  for  ATM  Layer  module. 


•  MGMT  int.  This  state  forwards  call  descriptor  information,  indicating  the 
status  of  a  call  request,  to  the  AAL  module. 

•  from  AAL.  When  a  48-byte  data  segment  arrives  from  the  AAL  module,  this 
state  is  entered  and  the  module  adds  the  appropriate  cell  header,  inserts  the 
data  segment  into  the  cell  payload,  and  forwards  the  newly  created  ATM  cell 
to  the  ATMjswitch  module  for  transmission. 

•  from  mgmt.  A  process  in  this  state  forwards  an  ATM  management  cell  to 
the  ATM^witch  module  for  transmission. 

•  to  AAL.  When  in  this  state,  the  module  processes  all  data  cells  addressed  to 
this  node.  After  removing  the  ATM  cell  header,  this  state  forwards  the  48-byte 
data  segment  to  the  AAL  module. 

d.  A  TM-mgmt  Module 

The  .A.TM_mgmt  module  manages  the  Virtual  Paths  (VPs)  and  Virtual 
Channels  (X'Cs)  for  all  calls  associated  with  a  node.  This  module  is  used  in  all  nodes 
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throughout  the  network.  For  a  node  that  originates  calls,  this  module  sends  and  co¬ 
ordinates  the  call  setup  and  connect  messaging.  For  an  intermediary  node  between  the 
source  and  destination,  this  node  assigns  a  VP  and  VC  and  then  forwards  the  setup 
message  on  to  the  next  node  enroute  to  the  destination.  For  a  destination  node,  the 
ATM_mgmt  module  forwards  a  call  request  to  the  ATM  Jayer  and  awaits  a  response 
from  the  ATMJayer  indicating  acceptance  or  rejection  of  the  call.  Based  on  the  ac¬ 
ceptance  or  rejection,  this  module  then  sends  the  appropriate  message,  corresponding 
to  the  acceptance  or  rejection,  back  to  the  source  node.  The  ATM_mgmt  process  state 
diagram  is  shown  in  Figure  34.  A  description  of  these  states  is  given  below. 


(dcfaalt) 


Figure  34.  State  diagram  for  ATM  Mgmt  module. 


•  INIT,  config,  and  wait.  These  states  provide  the  same  functions  in  support 
of  this  network  module  as  the  identically  named  states  defined  in  ATMJayer 
module  on  page  73. 
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•  route  start.  In  this  state,  the  module  spawns  a  dynamic  process  to  execute 
dynamic  routing.  The  routing  process  creates  a  routing  table  from  this  node  to 
all  other  nodes  within  the  network.  (A  full  description  of  the  dynamic  routing 
process  is  given  later  in  this  section.) 

•  AAL  intrpt.  This  state  is  used  to  parse  the  AAL  interrupt  type. 

•  AAL  Estab.  When  a  call  request  arrives,  this  state  is  used  to  process  the  AAL 
establishment  request  from  the  AAL  module.  This  state  spawns  a  dynamic 
process  called  call_src  which  then  handles  this  call  request.  (A  full  description 
of  the  dynamic  calljsrc  process  is  given  later  in  this  section.) 

•  AAL  other.  This  state  handles  other  AAL  module  requests  for  this  node  by 
forwarding  it  to  the  appropriate  dynamic  calljsrc  process  (which  was  previously 
created  in  an  AAL  Estab  state  that  corresponds  to  this  request). 

•  control  cell.  After  receiving  a  control  cell  from  the  network,  this  state  is  used 
to  determine  the  type  of  control  cell. 

•  ATM  setup.  For  a  call  establishment  request,  this  state  is  entered  and  the 
module  checks  the  destination  of  the  call.  If  this  node  is  the  destination,  this 
state  is  used  to  spawn  a  dynamic  process,  calLdst,  which  then  handles  this 
call  request.  If  this  is  not  the  destination  node,  this  state  spawns  a  dynamic 
process  called  call_net  which  forwards  the  call  request  on  to  the  next  node.  (A 
full  description  of  the  dynamic  calLdst  and  callmet  processes  are  given  later 
in  this  section.) 

•  ATM  signal  other.  In  this  state,  the  module  handles  other  ATM  control  cells 
sent  to  this  node.  If  a  dynamic  callmet  or  calLdst  already  exists  to  handle  the 
request,  this  state  forwards  it  to  the  appropriate  process.  If  the  signal  is  a 
network  call  release  request,  this  state  is  used  to  forward  the  release  request 
to  the  next  node  enroute  to  the  destination  address. 

•  routing  cell.  For  dynamic  routing  cells,  a  module  in  this  state  forwards  the 
routing  message  to  the  dynamic  routing  process  for  this  module. 

e.  ATM-trans  Module 

The  ATM-trans  module  handles  all  cells  received  from  the  ATM  net¬ 
work.  This  module  is  used  in  all  nodes  throughout  the  network.  It  first  determines  the 
type  of  an  ATM  cell:  control  or  data.  It  forwards  the  control  cells  to  the  ATM  mgmt 
module.  For  data  cells,  this  module  determines  whether  the  data  cell  is  destined  for 
this  node.  If  the  data  cells  is  destined  for  this  node,  the  module  forwards  it  to  the 
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ATMJayer  module,  otherwise  this  module  forwards  the  data  cell  to  the  ATM-Switch 
module.  The  ATM.trans  process  state  diagram  is  shown  in  Figure  35.  A  description 
of  these  states  is  given  below. 
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Figure  35.  State  diagram  for  ATM_trans  module. 


•  INIT,  config,  and  wait.  These  states  provide  the  same  functions  in  support 
of  this  network  module  as  the  identical  states  defined  in  ATMJayer  module  on 
page  73. 

•  ATM  cell.  This  state  determines  the  type  of  ATM  cell  that  arrived  from 
another  node  in  the  network. 

•  control  cell.  This  module  transitions  to  this  state  when  a  control  cell  arrives. 
It  forwards  the  control  cell  to  the  ATM_mgmt  module. 

•  data  cell.  This  state  is  reached  upon  reception  of  a  data  cell.  This  module 
delivers  the  data  cells  addressed  to  this  node  to  the  ATMJayer  module.  (For 
data  cells  addressed  to  other  nodes  in  the  network,  this  module  delivers  the 
data  cell  to  the  ATM_switch  module.) 

f.  ATM-Switch  Module 

This  module  forwards  ATM  cells  to  the  next  node  in  the  ATM  network. 
This  module  is  used  in  all  nodes  throughout  the  network.  The  ATMjswitch  process 
state  diagram  is  shown  in  Figure  36.  A  description  of  these  states  is  given  below: 
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Figure  36.  State  diagram  for  ATM_switch  module. 

•  INIT,  config,  and  wait.  These  states  provide  the  same  functions  in  support 
of  this  network  module  as  the  identical  states  defined  in  ATMJayer  module  on 
page  73. 

•  cell  arrival.  In  this  state,  the  module  processes  new  ATM  cells  as  they  arrive. 
It  places  all  cells  in  a  queue  for  transmittal.  All  cells  axe  held  in  this  queue  for 
an  amount  of  time  based  on  the  switching  fabric. 

•  cell  transmit.  In  this  state,  the  module  dequeues  the  next  ATM  cell  and 
sends  it  to  the  next  node  in  the  network,  using  a  direction  that  is  based  on  the 
addressing  information  contained  within  the  cell. 

2.  IDS  LAN  Dynamic  Processes 

This  section  describes  the  dynamic  processes  required  to  support  the  function¬ 
ality  of  the  modules  within  the  IDS  LAN  node. 
a.  SAAL  Process 

The  SAAL  process  is  a  dynamic  process  created  by  the  AAL  module 
to  handle  the  signaling  for  a  call  request.  It  exists  in  multiple  instantiations  in  the 
IDS  LAN  and  the  TACTICAL  LAN,  to  support  concurrent  calls  in  our  simulation. 
Each  SAAL  process  corresponds  with  a  peer  SAAL  process  at  the  destination  node 
to  process  the  call  request.  The  process  state  diagram  is  shown  in  Figure  37.  A 
description  of  these  states  is  given  below. 
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Figure  37.  State  diagram  for  SAAL  process. 


•  INIT.  In  addition  to  code  initializing  the  process’s  variables,  this  state’s  code 
determines  the  type  of  request  for  which  it  was  spawned. 

•  EReq.  This  state  is  used  to  forward  the  call  requests  from  the  application 
module  to  the  ATMJayer  module.  The  process  remains  in  this  state  awaiting 
a  response.  If  the  ATMJayer  responds  with  a  call  release  message,  this  state’s 
code  sends  the  application  module  a  message  canceling  the  call  request  and 
then  terminates  this  SAAL  process.  If  the  ATMJayer  responds  with  a  call 
connection  message,  this  state  spawns  a  dynamic  process  called  AAL5_Conn 
and  then  invokes  the  process  to  handle  the  AAL5  functions  for  this  call. 

•  ECon.  This  is  used  to  wait  for  the  network  to  acknowledge  the  request  to 
establish  the  connection. 


•  BGAK.  When  the  network  accepts  a  request  by  sending  an  acknowledgment, 
the  process  in  this  state  sends  a  message  to  the  application  module  to  start 
sending  data  packets.  If  the  network  rejects  the  request,  then  it  sends  the 
application  module  a  message  canceling  the  call  request  and  then  terminates 
this  SAAL  process. 

•  connect.  After  establishing  the  connection,  the  process  waits  in  this  state  until 
either  the  call  completes  or  the  network  abnormally  terminates  the  call. 

•  END.  When  a  call  successfully  completes,  the  SAAL  process  in  this  state  sends 
an  END  request  to  its  peer  SAAL  process. 

•  Rind.  After  sending  an  END  request  to  its  peer,  the  process  enters  the  Rind, 
where  it  awaits  the  response  from  the  network,  acknowledging  the  END  re¬ 
quest.  The  acknowledgment  indicates  the  network  has  freed  all  resources  as¬ 
sociated  with  the  call  request. 

•  kill.  The  process  in  this  state  destroys  the  dynamic  AAL5_conn  process  and 
this  SAAL  process. 

•  EInd.  The  SAAL  process,  at  the  destination  node,  enters  this  state  when  the 
call  request  is  delivered  from  the  ATM  Jayer  module.  In  this  state  the  process 
handles  the  request  by  forwarding  the  request  to  the  application  module.  The 
process  also  creates  a  dynamic  AAL5_conn  process  to  handle  the  call  request. 

•  BG.  The  SAAL  process  waits  in  this  state  for  a  response  from  the  application 
module.  If  the  application  module  accepts  the  call  request,  the  code  in  this 
state  generates  an  acknowledgment  for  the  call  source  node.  If  the  applica¬ 
tion  module  rejects  the  request,  the  process  destroys  the  dynamic  AAL5_conn 
process  and  this  SAAL  process. 

•  no  BGAK,  irreg  kill,  send  END,  no  ENDAK,  ENDAK,  and  RREQ. 

The  SAAL  process  in  these  states  handles  those  instances  when  the  network 
sends  a  negative  acknowledgment  to  a  request  or  fails  to  send  any  type  of 
acknowledgment. 

b.  AAL5-Conn  Process 

The  SAAL  process  creates  and  invokes  an  AAL5_conn  process  to  handle 
packet  segmentation  and  packet  reassembly  fxmctions.  When  spawned  by  a  sender, 
this  process  breaks  data  packets  received  from  the  application  layer  into  48-byte  seg¬ 
ments  and  forwards  the  segments  to  the  ATMJayer  module.  When  spawned  by  the 
receiver,  it  reassembles  the  48-byte  data  segments  from  the  ATMJayer  module  into 
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a  data  packets.  The  process  state  diagram  is  shown  in  Figure  38.  A  description  of 
these  states  is  given  below. 


Figure  38.  State  diagram  for  AAL5  Connection  process. 


•  setup.  When  in  this  state,  the  process  initializes  local  variables  and  creates 
the  buffers  used  for  segmentation  and  reassembly. 

•  data.  When  data  arrives,  the  process  enters  this  state  and  determines  the 
type  and  source  of  the  data.  For  call  requests  and  call  data  packets  from 
the  application  module,  the  process  transitions  to  the  to_atm  state.  For  data 
segments  from  the  ATM  Jayer  module,  it  transitions  to  the  from_atm  state. 

•  to_atm.  In  this  state,  the  AAL5_conn  process  decomposes  messages  into  48- 
byte  segments  and  sends  the  segments  to  the  ATM  Jayer  module. 

•  fr_atm.  When  the  process  enters  this  state,  it  reassembles  the  data  segments 
into  a  data  packet  and  forwards  the  packet  to  the  application  module. 

•  release.  In  this  state  the  process  decomposes  a  call  completion  message  from 
the  application  layer  into  48-byte  segments  and  sends  the  segments  to  the 
ATMJayer  module. 

•  data  rel.  After  starting  the  connection  release  process,  no  more  data  packets 
can  be  sent  but  additional  data  segments  are  still  accepted  from  the  ATMJayer. 
This  process  transitions  to  the  to_atm_rel  state  when  call  data  packets  arrive 
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and  transitions  to  the  from_atm  state  when  data  segments  from  the  ATM  Jayer 
module  arrive. 

•  to_atm_rel.  This  state  is  used  to  destroy  all  application  data  packets  received 
after  sending  the  connection  release  message. 

•  from_atm_rel.  In  this  state,  the  process  continues  to  accept  additional  ATM 
data  segments  until  the  connection  terminates. 

•  end.  This  state  is  used  to  destroy  the  AAL5_conn  process. 

c.  Routing  Process 

The  ATM_mgmt  process  creates  and  invokes  a  routing  process  to  handle 
call  routing  for  the  ATM  node.  This  process  constructs  and  maintains  the  dynamic 
routing  table.  The  routing  table  uses  an  adaptation  of  the  Bellman-Ford  Shortest 
Path  algorithm  [Ref.  16,  4].  The  process  state  diagram  is  shown  in  Figure  39.  A 
description  of  these  states  is  given  below. 


Figure  39.  State  diagram  for  Dynamic  Routing  process. 


•  INIT.  The  code  in  this  state  initializes  the  local  variables  and  creates  an  empty 
routing  table. 
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•  UPDATE.  Periodically,  the  routing  table  is  checked  for  accuracy.  In  this 
state,  the  routing  process  removes  any  old  links  from  the  routing  table  and 
recalculates  the  cost  for  all  current  routes.  The  code  in  this  state  also  broadcast 
the  address  resolution  packets  (ARP)  to  all  neighboring  nodes.  The  ARP 
ensures  that  all  neighbors  maintain  active  routes  containing  information  about 
the  current  node. 

•  WAIT.  When  in  this  state,  the  process  waits  for  an  event  to  occur. 

•  ARP.  The  process  transitions  to  this  state  when  address  resolution  packets 
arrive.  These  packets  are  used  to  verify  and  update  the  routing  table  as  neces¬ 
sary. 

•  ADVERT.  The  process  transitions  to  this  state  when  route  advertisement 
packets  arrive.  The  process  verifies  that  the  route  contained  in  the  route  ad¬ 
vertisement  packet  is  valid  and  that  the  route  does  not  cause  a  loop  in  the 
network.  The  process  then  updates,  using  the  new  route,  the  cost  of  all  routes 
in  the  routing  table. 

•  QUERY.  When  in  this  state,  another  process  has  requested  the  shortest  route 
to  a  particular  destination  node.  The  code  in  this  state  searches  the  routing 
table  to  determine  the  best  route  available  and  verifies  that  the  route  is  still 
available.  It  returns  the  output  port  nmnber  for  the  best  route  to  the  destination 
node. 

•  FAILURE.  Because  a  link  failed  in  the  network,  this  process  must  update  the 
routing  table  by  removing  the  link  and  calculating  a  new  cost  for  routes  previ¬ 
ously  using  the  failed  link.  Additionally,  the  code  within  this  state  broadcasts 
a  route  advertisement  packet  to  all  neighboring  nodes  notifying  them  of  the 
new  cost  of  all  routes  through  the  current  node. 

•  RECOVERY.  During  a  simulation,  nodes  may  be  programmed  to  temporar¬ 
ily  fail  and  then  recover  from  the  failure.  When  failure  occurs,  OPNET  issues  a 
recovery  interrupt.  The  process  transitions  to  this  state  to  handle  the  recovery 
interrupt  and  it  then  transitions  to  the  UPDATE  state. 

d.  CalLSrc  Process 

The  ATM_mgmt  process,  at  the  calling  node,  creates  and  invokes  a 
call-src  process  for  each  VCC  to  handle  ATM  signaling  (VCC  setup  and  release). 
This  process  is  then  destroyed  at  connection  termination.  The  process  state  diagram 
is  shown  in  Figure  40.  A  description  of  these  states  is  given  below. 
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Figure  40.  State  diagram  for  Call_Src  process. 


•  INIT.  This  state  is  responsible  for  initializing  numerous  variables  within  the 
process  model.  Additionally,  this  state  obtains  the  call  description  from  the 
ATMjngmt  module. 

•  Call  Route.  Code  in  this  state  determines  whether  a  route  exists  from  the 
source  node  to  the  destination  node  and  ensures  sufficient  bandwidth  is  avail¬ 
able  on  the  route.  This  state  invokes  the  dynamic  routing  process  created  by 
the  ATM_mgmt  module. 

•  Call  Initiated.  Here  the  module  sends  a  setup  message  to  the  next  node 
enroute  to  the  destination  node.  The  process  then  waits  in  this  state  for  a 
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response  from  the  network.  The  network  may  accept  the  call,  reject  the  call, 
or  not  respond  at  cdl. 

•  call  alloc.  When  the  network  responds  with  a  call  accept  or  call  proceeding 
message,  this  state’s  code  allocates  resources  at  the  source  node  to  support  the 
call  request. 

•  Outgoing  Call  Proceeding.  Code  in  this  state  waits  for  the  connection 
request  to  propagate  through  the  network. 

•  Active.  This  state  is  reached  when  a  ‘connect’  message  is  received  from  the 
network,  meaning  that  the  connection  is  available  for  data  transmission.  It 
then  sends  the  ‘connect  ack’  message  to  the  first  intermediate  node. 

•  Release  Request.  When  in  this  state,  the  module  handles  the  release  connec¬ 
tion  request  by  first  sending  the  ‘release  connection’  message  to  the  network. 
After  the  network  releases  the  connection,  it  sends  a  ‘release  confirm’  message 
to  the  AAL  module. 

•  NULL.  Code  in  this  state  is  responsible  for  releasing  the  connection  resources 
at  the  source  node  and  destroying  this  calibre  process. 

•  reject  call,  release  cmpl,  and  release  indication.  These  remaining  states 
handle  those  instances  when  the  network  rejects  a  connection  request  or  simply 
fails  to  respond  to  a  connection  request. 

e.  CallJSfet  Process 

The  ATM_mgmt  process,  at  each  intermediate  node,  creates  and  invokes 
a  call-net  process  for  each  VCC  to  handle  ATM  signaling  (VCC  setup  and  release). 
This  process  is  destroyed  at  connection  termination.  The  process  state  diagram  is 
shown  in  Figure  41.  A  description  of  these  states  is  given  below. 

•  INIT.  In  the  INIT  state  numerous  variables  within  the  process  model  are 
initialized.  Additionally,  this  state  determines  whether  the  connection  request 
previously  passed  through  this  node. 

•  No  Fwd  Call.  If  this  state  is  reached  we  know  that  the  connection  request 
previously  passed  through  this  node,  and  consequently  the  code  destroys  both 
the  request  and  this  process. 

•  Call  Initiated.  Here  the  module  determines  whether  a  VP  and  a  VC  are 
available  to  support  the  connection. 
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•  release  cmpl.  When  resources  are  not  available  to  support  the  connection 
request,  this  state  is  used  to  send  a  connection  rejection  message  to  the  source 
node  after  which  it  destroys  this  process. 

•  Outgoing  Call  Proceeding.  When  resources  are  available  to  support  the 
connection  request,  this  state  is  used  to  assign  resources  to  the  connection. 

•  Call  Present.  This  state  is  used  to  send  a  setup  message  to  the  next  node 
enroute  to  the  destination  node.  The  process  then  waits  for  a  network  response. 
The  network  may  accept  the  connection,  reject  the  connection,  or  not  respond 
at  all. 

•  Connect  Request.  When  the  network  accepts  the  connection,  this  state  is 
used  to  forward  the  acceptance  towards  the  source.  The  module  also  sends  a 
connection  acknowledgment  to  the  previous  node. 

•  Active.  Reaching  this  state  means  that  the  connection  is  available  for  data 
transmission.  The  process  then  remains  in  this  state  awaiting  a  signal  to  release 
the  connection. 

•  Release  Indication.  When  this  state  is  reached,  the  network  hats  rejected  the 
call  or  failed  to  respond  to  the  connection  request.  The  process  then  sends  a 
call  release  message  to  all  the  other  nodes  within  the  network. 

•  call  clear  and  call  clear  cont.  These  states  are  used  to  free  resources 
allocated  to  a  connection  and  to  send  a  release  message  to  other  nodes  within 
the  network. 

•  NULL.  This  state  destroys  this  call_net  process. 

f.  CalLDst  Process 

The  ATMmigmt  process,  at  the  destination  node,  creates  and  invokes 
a  call-net  process  for  each  VCC  to  handle  ATM  signaling  (VCC  setup  and  release). 
This  process  is  destroyed  at  connection  termination.  The  process  state  diagram  is 
shown  in  Figure  42.  A  description  of  these  states  is  given  below. 

•  INIT.  This  state  is  used  to  initialize  numerous  variables  within  the  process 
model. 

•  Call  Init.  After  the  arrival  of  a  connection  request,  a  process  in  this  state 
determines  whether  resources  are  available  to  support  the  call. 
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Figure  42.  State  diagram  for  CallJDst  process. 


•  Call  Present.  When  resources  are  available  this  state  is  used  to  allocate  the 
necessary  resources  and  send  the  call  request  to  the  AAL  module  at  the  des¬ 
tination  node.  Additionally,  it  sends  a  call  proceeding  message  to  the  previous 
intermediate  node  in  the  network. 

•  Connect.  If  the  AAL  accepts  the  call  request,  this  state  is  used  to  send  the 
connect  message  to  the  intermediate  node  in  the  network. 

•  Active.  This  state  is  reached  when  the  connection  is  available  for  data  trans¬ 
mission.  The  process  waits  in  this  state  for  the  AAL  module  to  signal  call 
completion  or  for  the  network  to  drop  the  connection.  If  the  AAL  module 
signals  call  completion,  the  next  state  is  the  Release  Request  state.  If  the 
network  dropped  the  connection,  the  transition  is  to  the  Release  Indication 
state. 

•  Release  Request.  This  state  is  used  to  send  a  release  connection  message  to 
other  nodes  in  the  network  and  waits  for  a  response  from  the  network. 

•  Release  Indication.  A  process  in  this  state  sends  a  release  acknowledgment 
message  to  the  previous  node  in  the  network. 

•  call  rejected.  This  state  is  used  to  send  the  connection  rejection  message  to 
other  nodes  in  the  network. 

•  NULL.  This  state  is  used  to  return  resources  that  were  allocated  to  the  con¬ 
nection  and  to  destroy  the  calLdst  process. 

3.  Uplink  LDR  and  Dnlink  LDR 

For  our  network,  we  chose  to  represent  the  Uplink  LDR  and  Dnlink  LDR  as 
simple  ATM  switches.  Figure  43  shows  the  node  diagram  for  our  LDR  switch.  This 
node  contains  the  four  ATM  modules  that  we  discussed  in  the  previous  section.  Unlike 
the  IDS  LAN  these  nodes  support  three  communication  links  rather  than  one.  The 
three  transceiver  links  are  represented  by  the  following  modules:  (pr_0,  pt_0),  (pr_l, 
pt_l),  and  (pr_2,pt-2).  Two  of  these  links  support  a  transmission  channel  capacity 
of  155  Mbps.  The  third  supports  only  an  8  Mbps  channel  capacity.  The  low  data 
rate  channel  represents  the  BADD  ATM  channel  capacity  available  through  the  GBS 
system. 
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Figure  43.  Uplink  and  Dnlink  Low  Data  Rate  switch  node  diagram. 

4.  Tactical  LAN  Subnetwork 

The  Tactical  LAN  subnet  in  our  model  contains  a  single  WFA  switch  and  the 
traffic  destination  as  shown  in  Figure  44.  Our  model  is  extensible  in  that  it  would 
require  very  little  modification  to  add  additional  WFA  switches  and  traffic  destination 
modules. 


WFA^SWITCH  U3iV_dest 


Figure  44.  Tactical  LAN  Subnetwork  diagram. 
a.  WFA  Switch 

The  WFA  switch  is  similar  to  the  Uplink  LDR  switch  shown  in  Fig¬ 
ure  43.  It  contains  the  four  ATM  modules  and  two  transceivers,  both  with  a  channel 
capacity  of  155  Mbps. 
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b.  Traffic  Destination 

The  traffic  destination  node  is  similar  to  our  traffic  source  in  Figure  30. 
The  only  difference  is  that  the  call-generator  has  been  replaced  with  a  traffic  sink.  As 
data  segments  arrive  at  the  destination  node  they  are  reassembled  by  the  AAL  module 
and  forwarded  to  the  traffic  sink.  The  traffic  sink  updates  requested  statistics  and 
then  destroys  the  data  packet. 

5.  Network  Communication  Links 

After  defining  the  nodes  within  the  network,  we  connected  the  nodes  by  using 
OPNET  commimication  links.  As  mentioned  earlier  in  this  section,  OPNET  currently 
does  not  support  simplex  ATM  channels,  therefore  we  first  inserted  the  standard 
OPNET  duplex  communication  links,  then  modified  the  code. 

Our  model  utilizes  two  types  of  communication  links:  one  with  a  capacity  of 
155  Mbps  and  the  other  with  a  capacity  of  8  Mbps.  The  standard  communication  link 
with  155  Mbps  capacity  connects  the  traffic  source  with  the  Uplink  LDR,  the  Dnlink 
LDR  with  the  WFA  switch,  and  the  WFA  switch  with  the  traffic  destination.  We 
modeled  this  link  after  a  standard  fiber  optic  connection  with  no  errors  and  no  delay. 

For  the  backbone  connection  between  the  Uplink  LDR  and  the  Dnlink  LDR,  we 
created  a  link  with  a  capacity  of  8  Mbps  using  the  OPNET  parameter  editor  described 
in  Chapter  V.  Initially,  we  defined  the  communication  link  with  a  transmission  delay 
of  0.25  seconds  which  is  a  typical  delay  time  for  a  single  geosynchronous  satellite 
transmission. 

6.  Modification  of  Our  Initial  OPNET  Modeler 

After  constructing  our  initial  OPNET  model,  we  began  testing  to  verify  that 
the  network  was  being  correctly  simulated.  When  we  ran  simulations  with  the  link 
delay  set  to  0.25  seconds,  the  simulation  terminated  abnormally  giving  the  error 
message  ‘traffic-dest  received  process  handle  for  destroyed  process.’  Tracing  the 
code,  we  found  a  simulation  timer  called  AMSC_AAL_TIMER_CC_DURATION  in 
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the  ams_aalJnterfaces.h  file.  This  timer  defines  the  maximum  amount  of  time,  in 
seconds,  that  an  AAL  process  can  wait  for  a  response  to  the  connection  request  mes¬ 
sage.  This  variable  was  originally  defined  as  0.25  seconds;  we  changed  the  timer  to 
10.0  seconds  and  the  simulation  ran  successfully. 

Another  problem  that  we  encountered  in  the  testing  of  our  basic  network  model 
was  the  calculation  of  Peak  Cell  Rate  (PCR)  for  small  calls.  When  the  packet  size 
is  less  than  384  bits,  OPNET  calculates  the  PCR  to  be  0.  Again,  tracing  the  code  we 
found  the  problem  to  be  integer  division.  We  modified  the  OPNET  code  to  explicitly 
cast  the  calculation  as  a  float,  which  yields  a  correct  PCR. 

C.  STATIC  CHANNELS  WITHIN  B ADD  ATM  NETWORK 

The  next  phase  of  our  network  design  required  the  definition  of  static  channels 
within  the  BADD  ATM  network.  Chapter  II  describes  the  call  setup  protocol  for 
virtual  channel  definition  within  ATM.  Normally  virtual  channels  are  created  and 
destroyed  dynamically  by  the  network.  Because  the  GBS  backbone  within  BADD 
only  allows  simplex  communication,  BADD’s  designers  chose  to  define  static  channels 
for  the  Uplink  LDR  and  Dnlink  LDR  during  network  configuration. 

To  simulate  this  configuration,  we  modified  our  network  in  two  phases.  In  the 
first  phase  we  defined  static  channels  at  each  ATM  switch  within  the  network  and  in 
the  second  phase  we  modified  the  network  to  use  the  static  channels. 

For  phase  one,  we  modified  the  ATM_mgmt  module,  described  on  page  74,  by 
adding  a  state  called  static_channels_setup.  The  new  ATM_mgmt  module  is  shown 
in  Figure  45. 

The  code  for  the  newly  added  static.channels-setup  state  begins  by  opening  the 
input-channels  file  and  reading  the  first  line.  The  first  line  contains  a  single  integer 
value  defining  the  number  of  static  channels  for  the  network.  The  maximum  allowable 
channels  are  1024  [Ref.  10].  Each  subsequent  line  in  the  input -channels  file  defines 
a  single  channel  by  giving  its  bandwidth  capabilities.  This  state  is  then  used  to  add 
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Figure  45.  State  diagram  for  BADD  ATM  Mgmt  module. 

the  static  channels  to  each  ATM  path  and  allocate  the  bandwidth  to  the  channels  as 
defined  in  the  input  .channels  file. 

The  second  phase  requires  the  modification  of  the  call.src,  callmet  and  calLdst 
modules.  Each  of  these  modules  called  functions  for  creating  and  destroying  virtual 
channels  as  described  on  pages  83  through  87.  We  created  new  functions  for  alloc¬ 
ating  only  the  static  channels  and  deallocating  the  channels.  In  the  call.£rc  module, 
we  modified  the  states  call  route,  release  cmpl,  call  alloc,  release  indication, 
and  NULL  to  call  our  new  functions.  In  the  callmet  module,  we  similarly  modi¬ 
fied  the  states  call  initiated,  outgoing  call  processing,  and  call  clear  to  invoke 
our  new  functions.  Similarly,  in  the  calLdst  module,  we  modified  the  code  for  the 
states  Call  Init,  Call  Present,  and  NULL.  Appendix  B  contains  the  code  for  these 


modifications. 

Although  the  simulation  ran  successfully,  link  utilization  was  extremely  low  as 
shown  in  Figure  46.  We  found  that  the  network  spent  the  majority  of  time  sending 
ATM  control  data  to  setup  and  tear  down  a  connection.  Although  this  overhead  is 
typical  for  duplex,  dynamic  channels,  it  should  be  absent  in  simplex,  static  virtual 
channels. 

According  to  OPNET  Communication  Mechanisms,  any  delay  defined  on  a 
communication  link  is  applied  equally  to  all  data  traversing  the  link  [Ref.  4].  This 
means  that  all  ATM  cells,  including  both  data  and  control  cells,  traversing  the  GBS 
backbone  are  delayed  for  0.25  seconds.  This  application  of  delay  is  not  appropriate 
for  the  BADD  network  because  the  link  is  simplex  with  static  virtual  channels.  Static 
channels  on  the  satellite  link  are  defined  at  the  switches  and  there  is  no  need  for 
signaling.  In  addition,  since  the  satellite  link  is  simplex  there  is  no  signaling  coming 
back  from  the  downlink  to  the  uplink.  Since  we  were  using  the  OPNET  duplex 
implementation  as  a  baseline,  we  resolved  these  conflicts  by  setting  the  communication 
link  delay  to  0.0  seconds  and  rewriting  the  ATMjswitch  module  to  send  only  data  cells 
with  a  0.25  second  delay  over  the  GBS  backbone.  This  modification  triples  the  link 
utilization  as  illustrated  in  Figure  47. 

D.  FINAL  BADD  TRAFFIC  SOURCE 

In  the  initial  design  we  described  only  a  single  call  generator.  In  this  section 
we  describe  our  experiences  when  adding  additional  call  generators.  As  we  increased 
the  number  of  call  generators  we  observed  that  calls  were  being  dropped.  ATM  nor¬ 
mally  drops  call  requests  when  sufiicient  resources  are  unavailable  to  handle  the  call 
requested.  When  a  rejection  was  sent  to  our  call  generator,  it  would  respond  by  im¬ 
mediately  issuing  another  request.  This  looping  process  lead  to  a  dramatic  increase 
in  the  number  of  call  requests  and  call  rejections.  This  problem  lead  us  to  redesign 
our  traffic  source  node  as  depicted  in  Figure  48.  This  section  describes  the  function 
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Figure  46.  Initial  link  utilization  for  our  basic  BADD  network. 
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Figure  47.  Link  utilization  after  modification  of  our  basic  BADD  network. 
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of  our  modified  calljrequester  module,  our  new  call_scheduler  module,  and  our  new 
dynamic  process  called  call-generator. 


Figure  48.  Node  Diagram  for  our  new  BADD  Traffic  Source. 

1.  BADD  Call  Requester 

OPNET’s  call-generator  module  generates  a  single  call,  waiting  until  the  com¬ 
pletion  of  the  previous  call  before  starting  the  next  call.  When  we  began  queuing  calls 
to  await  resources,  the  call-generator  process  would  not  generate  another  call  until  the 
call  had  been  removed  from  the  queue  and  processed.  This  wait  time  does  not  repres¬ 
ent  a  realistic  scenario,  i.e.,  a  database  server  does  not  wait  for  an  acknowledgment 
indicating  that  its  last  response  was  sent  to  the  final  destination  before  processing  the 
next  query.  To  correct  this  problem,  we  divided  the  call  generation  process  into  two 
distinct  processes:  call  request  generation  and  data  generation. 
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Figure  49  shows  our  new  call_requester  module.  This  process  iteratively  gen¬ 
erates  a  call  request  and  then,  using  the  input  mean  interarrival  rate,  generates  the 
event  for  the  time  to  generate  the  next  call  and  continues  processing  regardless  of  the 
status  of  the  requested  call.  A  description  of  the  call-requester  states  is  given  below. 


(defiiut) 
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Figure  49.  State  diagram  for  BADD  call-requester  module. 


•  INIT,  config,  schedule,  and  -wait.  These  states  provide  the  same  functions 
in  support  of  this  network  module  as  the  identical  states  defined  in  our  initial 
call -generator  module  on  page  70. 

•  start.  When  the  module  enters  this  state,  it  creates  a  badd-call_req if  Jci  packet 
describing  the  call.  The  module  attributes  read  during  the  INIT  state  axe 
copied  into  the  Ici  packet  before  it  passes  the  call  request  to  the  call-scheduler 
module.  Lastly,  this  module  generates  an  event,  in  the  future,  at  which  time 
the  module  will  schedule  the  next  call  request. 

•  wait-call-duration.  The  module  remains  in  the  wait_call_duration  state 
until  the  time  for  the  event  generated  in  the  previous  start  state  arrives.  The 
module  then  transitions  back  to  the  schedule  state. 
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2.  BADD  Call  Scheduler 

The  call-scheduler  module  accepts  call  requests  and  schedules  the  calls  for 
transmission  over  the  static  chajinels.  The  state  diagram  for  our  new  call_scheduler 
module  is  shown  in  Figure  50.  A  description  of  the  calljscheduler  states  is  given  below: 

•  INIT.  In  this  state,  the  module  initializes  local  variables  and  reads  the  model 
attribute  variables.  The  model  attributes,  calls  pending  and  scheduler  delay, 
define  the  maximum  number  of  call  requests  that  will  be  allowed  to  be  enqueued 
before  they  are  assigned  a  time  and  virtual  channel.  The  scheduler  delay  is  the 
maximum  time  that  any  request  can  remain  in  the  queue  before  it  is  assigned 
a  time  and  chajanel.  While  in  this  state,  the  module  also  creates  the  global  wait 
queue  and  the  individual  static  channel  queues. 

•  config.  This  state  provides  the  same  functions  in  support  of  this  network 
module  as  the  identical  state  defined  in  our  initial  calLgenerator  module  on 
page  70. 

•  shared  data.  The  module  transitions  to  this  state  after  neighbor  notification, 
discussed  at  page  70  ,  is  completed.  The  code  in  this  state  initializes  variables 
shared  by  all  the  processes  within  the  call^cheduler  module.  The  calljscheduler 
will  later  spawn  a  dynamic  call^enerator  process  which  will  access  these  shared 
variables  to  determine  the  current  ATM  network  configuration. 

•  dispatch.  The  code  in  this  state  functions  as  a  task  dispatcher,  starting  tasks 
based  on  the  type  of  interrupt  received. 

•  call  request.  Upon  the  arrival  of  a  call  request,  this  module  transitions 
from  the  dispatch  state  to  the  call  request  state  where  it  inserts  the  call 
request  into  the  calls.pending  list.  The  calls_pending  list  contains  all  of  the 
calls  that  require  scheduling.  After  adding  the  call  to  the  calls.pending  list, 
control  returns  to  the  dispatch  state. 

•  call  schedule.  If  the  number  of  calls  in  the  calls_pending  list  exceeds  the 
calls.pending  attribute,  or  the  scheduler  delay  attribute  timer  expires,  then 
the  module  transitions  from  the  dispatch  state  to  the  call  schedule  state. 
Upon  entering  the  call  schedule  state,  the  code  schedules  all  of  the  calls  in 
the  calls_pending  list  by  assigning  each  call  to  a  static  channel  according  to 
one  of  the  scheduling  algorithms  described  in  chapter  IV.  As  calls  are  added 
to  a  static  channel,  the  call  is  time-stamped  with  the  time  it  was  enqueued. 
When  calls  are  scheduled  on  an  idle  channel,  the  module  generates  a  calljstart 
signaling  event  that  starts  the  first  call  on  the  idle  channel.  After  scheduling 
all  available  calls,  the  module  transitions  back  to  the  dispatch  state. 
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•  start  call.  When  the  call^tart  event  arrives,  the  module  transitions  to  this 
state.  The  module  dequeues  the  first  call  for  the  channel  and  spawns  a  dynamic 
call-generator  process  and  assigns  that  process  to  handle  this  call.  It  then 
transitions  back  to  the  dispatch  state.  (The  description  for  call-generator 
process  follows  in  the  next  subsection.) 

•  send  data.  Because  all  signals  for  a  dynamic  call.generator  process  are  re¬ 
turned  to  the  parent  call.scheduler  module,  there  must  exist  a  mechanism 
whereby  it  can  identify  which  call-generator  to  invoke.  OPNET  uses  a  process 
pointer,  called  prohandle,  to  uniquely  identify  each  dynamic  process.  All 
signals  returned  to  the  call.scheduler  contain  the  prohandle  for  the  required 
call-generator.  Since  the  call-generator  process  invoked  in  the  call  start  sends 
a  call  connection  request  to  the  AAL  module,  the  AAL  module  signals  the 
call^cheduler  when  the  connection  is  established.  This  signal  forces  a  trans¬ 
ition  from  the  dispatch  state  to  the  state  send  data  state.  This  module  awakes 
the  sleeping  call-generator  process  and  signals  the  call-generator  to  start  send¬ 
ing  data  on  the  established  connection.  After  invoking  the  call-generator,  the 
module  again  transitions  to  the  dispatch  state. 

•  call  complete.  The  call-generator  continues  to  send  data  until  the  call  com¬ 
pletes  transmission.  The  call-generator  then  signals  the  AAL  module  to  release 
and  close  the  connection.  The  AAL  module  again  signals  the  call-scheduler 
after  releasing  the  connection.  This  release  connection  signal  forces  a  trans¬ 
ition  to  the  call  complete  state.  Upon  entering  this  state,  the  module  invokes 
the  requested  call-generator  and  signals  the  call-generator  with  a  release  con¬ 
firmed  acknowledgment.  As  before,  the  module  transitions  to  the  dispatch 
state. 

•  check  channel.  When  the  call-generator  receives  the  signal  that  the  release 
was  confirmed,  the  call..generator  notifies  the  call-scheduler  that  the  channel  is 
available.  This  signal  forces  a  transition  to  the  check  channel  state  where 
the  channel  list  is  checked  for  additional  calls  waiting.  If  additional  calls  are 
scheduled  on  the  channel,  the  module  generates  an  event  to  start  the  next  call 
on  the  channel. 

•  call  release.  This  state  is  released  when  the  call-generator  sends  a  call  con¬ 
nection  request  to  the  AAL  module  and  the  AAL  module  responds  with  a  call 
rejection.  The  module  invokes  the  required  call-generator  and  passes  along  the 
call  rejection  signal. 

•  reschedule.  When  the  call^enerator  receives  a  call  rejection  signal,  it  creates 
a  call  reschedule  request  and  signals  the  calljscheduler  to  reschedule  the  call. 
The  signal  to  reschedule  forces  a  transition  to  the  reschedule  state  which 
places  the  call  request  at  the  head  of  the  calls-pending  list  for  rescheduling. 
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•  error.  The  code  in  this  state  processes  unexpected  signals. 

•  End  Sim.  The  code  in  this  state  prints  reports  at  the  end  of  the  simulation. 

3.  BADD  Call  Generator 

The  dynamic  call..generator  process  is  created  and  invoked  by  the  call-scheduler 
module  to  manage  individual  call  requests.  This  process  initiates  the  call  connection 
request,  generates  data  for  the  call,  and  releases  the  call  upon  its  completion.  Figure  51 
shows  our  new  call-generator  process.  A  description  of  these  states  is  given  below. 


Figure  51.  State  diagram  for  BADD  call^enerator  process. 


•  INIT.  The  calLgenerator  enters  this  state  only  upon  initial  invocation  by  the 
call-scheduler  module.  This  state  accepts  the  call  request  Ici  packet  and  initial¬ 
izes  the  state  variables  that  describe  the  call  request.  Additionally,  this  state 
accesses  the  shared  memory  initialized  by  the  calljscheduler  and  retrieves  the 
index  identifying  the  packet  stream  to  the  AAL  module.  All  call  requests  and 
the  call  data  are  sent  to  the  AAL  module  using  this  stream  index. 
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•  start.  With  the  automatic  transition  to  this  state,  the  call^enerator  creates  a 
badd-calLgenJfJci  packet  describing  the  connection  required  to  support  this 
call.  It  includes  this  packet  in  the  call  connection  request  sent  to  the  AAL 
module.  This  process  then  goes  to  sleep  in  this  state,  awaiting  a  wake-up 
signal  from  the  calljscheduler  module. 

•  EstCon.  The  call-generator  received  a  wake-up  signal  from  the  call-Scheduler 
and  the  signal  contains  the  response  for  the  connection  request  sent  to  the  AAL 
module.  If  the  signal  is  an  established  connection  signal,  this  state  generates 
a  delayed  self  interrupt  to  signal  the  call  termination  and  then  generates  an 
immediate  interrupt  to  signal  generation  of  the  first  data  packet.  Control  im¬ 
mediately  transfers  to  the  data  gen  state.  If  the  signal  from  the  call-scheduler 
indicates  call  rejection  by  the  AAL  module,  this  state  transfers  control  to  the 
reschedule  state. 

•  data  gen.  This  state  continues  to  generate  data  packets  until  the  call  completes 
or  the  call-Scheduler  sends  a  network  release  indication.  Upon  receiving  the 
interrupt  signaling  call  completion,  this  state  sends  a  call  release  request  to  the 
AAL  module  and  transitions  to  the  RelCon  state.  If  the  network  signals  with 
a  connection  release,  this  state  transitions  to  the  reschedule  state. 

•  RelCon.  After  completing  the  call  and  sending  the  release  request,  this  state 
sleeps  until  the  network  responds  with  a  release  confirmed  signal.  This  signal 
forces  the  transition  to  the  call  done  state. 

•  reschedule.  When  a  call  is  rejected  by  the  network,  or  the  network  signals 
a  call  release  during  data  transmission,  the  current  call  requires  rescheduling. 
This  state  creates  a  call  request  that  is  forwarded  to  the  call-scheduler  module. 
This  state  then  signals  the  call-scheduler  module  that  the  channel  is  available 
and  then  destroys  this  process. 

•  call  done.  When  the  call  is  completed  and  all  network  resource  are  released, 
this  state  signals  the  call-scheduler  module  that  the  channel  is  available  and 
then  destroys  this  process. 

E.  SUMMARY 

In  this  chapter  we  have  explained,  in  detail,  the  design  and  implementation  of 
our  OPNET  Model  of  the  BADD  network.  Due  to  the  complexity  of  the  simulation 
model,  we  have  only  been  able  to  elaborate  on  the  most  significant  aspects  of  our 
design.  Additional  information  can  be  found  in  Appendices  C  through  F  which 
contain  the  OPNET  reports  for  the  processes  designed  to  support  our  simulations. 
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Now  that  our  simulation  model  is  defined  it  is  time  to  put  it  to  work.  The  next  chapter 
describes  our  simulation  testing  plan,  our  results,  and  conclusions. 
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VII.  ANALYSIS  AND  RECOMMENDATIONS 


In  this  chapter  we  describe  our  experiments  and  the  results  of  our  testing.  Since 
most  of  our  efforts  concentrated  on  the  construction  of  the  simulation  of  BADD,  we 
provide  a  section  on  our  observations  from  using  OPNET  as  a  network  development 
tool  as  well  as  one  on  lessons  learned.  We  also  make  recommendations  for  new  features 
that  we  would  like  to  see  in  a  tool  for  building  prototype  networks.  Finally,  we  describe 
possible  areas  of  future  research  that  build  upon  our  simulation  model. 

A.  TESTING 

We  conducted  multiple  runs  of  our  simulator  using  both  the  default  FIFO 
scheduler  and  our  Greedy  scheduler  implementation.  We  initially  validated  our  basic 
model  using  only  a  single  data  generation  source  and  channel.  We  validated  our 
design  and  ensured  the  correctness  of  the  values  generated  by  the  simulation.  After 
verifying  the  correctness  of  our  basic  model,  we  ran  additional  simulations  varying 
the  parameters  described  in  Table  XII  using  small  data  sets  as  reflected  by  the  short 
durations  of  the  calls  and  the  small  numbers  of  channels  and  requesters.  Small  data 
sets  were  used  to  determine  the  sensitivity  of  our  simulations  to  changes  of  various 
parameters.  Next  we  conducted  additional  runs  to  determine  whether  our  analysis  of 
the  smaller  data  sets  holds  fot  the  larger,  more  realistic  data  sets.  Finally,  we  used  an 
exponential  distribution  for  the  interarrival  rates  and  wait  times  of  the  call  requesters 
to  determine  whether  our  analysis  held  for  more  general  cases. 

1.  Simulation  Duration 

We  varied  the  runtime  of  our  simulation  between  10  and  50  seconds.  A  runtime 
of  at  least  10  seconds  was  needed  to  allow  the  simulation  to  complete  its  warmup  phase, 
a  phase  that  is  common  to  all  simulations  [Ref.  17].  We  selected  the  maximum  of  50 
seconds  because,  by  that  time,  the  bit  throughput  clearly  approached  its  asymptotic 
limit  as  reflected  in  Figure  52.  OPNET  simulations  complete  in  any  of  three  ways: 
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Parameter 

Range 

Duration  of  Simulation 

10  to  50  seconds 

Number  of  Requesters 

1  to  16 

Number  of  Channels 

2  to  20 

Data  Sources  and 
Channel  Characterization 

nearly  homogeneous  to  heterogeneous 

Table  XII.  Simulation  Parameters  and  Ranges  of  Values 

(i)  when  the  simulated  time  reaches  a  certain  value,  (ii)  when  a  module  within  the 
network  reaches  a  final  state,  or  (iii)  in  unusual  circumstances,  when  the  event  list 
is  empty.  We  used  the  first  option  and  set  a  simulation  completion  time  to  end  our 
simulation. 


Figure  52.  Greedy  bit  throughput  results  after  100  Seconds. 


2.  Channels 

We  varied  the  number  of  channels  between  2  and  20  in  order  to  provide  a  wide 
range  for  analysis.  The  BADD  architecture  proposes  to  use  1024  channels  on  this  8 
Megabit  link.  This  configuration  requires  that  the  bandwidth  on  individual  channels  be 


106 


very  small.  Since  one  of  the  requirements  of  BADD  is  to  broadcast  bandwidth  intensive 
application  we  believe  that  some  large  channels  are  required.  The  use  of  a  few  large 
bandwidth  channels  brings  down  the  total  number  of  usable  channels  drastically.  In 
fact,  we  constructed  a  bandwidth  allocation  Lotus  1-2-3  spreadsheet  and  determined 
that  we  could  get  a  good  mix  of  channels,  of  standard  size,  if  we  limit  the  total 
ntimber  of  channels  to  20.  Typically,  telecommunication  channels  are  allocated  in 
bits-per-second  (bps)  with  standard  capacities  being  64  kilobits-per-second  (Kbps), 
128  Kbps,  256  Kbps,  512  Kbps,  and  1.544  megabits-per-second  (Mbps).  We  confined 
ourselves  to  using  a  mix  of  these  standard  channel  capacities  as  shown  in  Table  XIII. 
We  used  the  smaller  values  in  the  table  to  perform  our  sensitivity  analysis  on  our 
other  test  parameters.  We  recognized  that  BADD’s  8Mbps  channel  would  not  be 
completely  utilized  during  the  simulations  with  8  or  fewer  channels.  Nonetheless, 
these  experiments  permitted  us  to  perform  the  sensitivity  analysis  to  determine  which 
parameters  most  influenced  the  simulation  results. 

In  Table  XIII  we  list  2  columns,  heterogeneous  and  homogeneous  channel 
mixes.  We  provide  these  columns  to  support  our  definition  of  heterogeneous  and 
homogeneous  experiments.  For  heterogeneous  experiments  we  will  use  heterogeneous 
data  sources  over  heterogeneous  channels.  Similarly,  for  homogeneous  experiments  we 
will  use  homogeneous  data  sources  over  homogeneous  channels.  These  data  source 
classifications  will  be  discussed  fully  in  the  next  section. 

3.  Number  of  Call  Requesters  and  Data  Sources 

We  varied  the  number  of  requesters  between  2  and  16.  We  were  constrained  to 
16  by  OPNET’s  limitations  on  the  numbers  of  requesters  that  can  be  connected  into 
the  AAL  module.  The  OPNET  GUI  for  building  nodes  does  not  allow  the  lines  that 
represent  data  streams  that  connect  modules  to  intersect.  Because  of  the  physical 
limits  of  connecting  data  streams  graphically,  we  experienced  difficulty  when  we  tried 
to  use  more  than  16  requesters. 

Table  XIV  lists  the  variety  of  data  sources  that  we  used  for  testing  with  smaller 
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Number  of  Channels 
Allocated 

Heterogeneous 
Mix  of  Channels 

Homogeneous 
Mix  of  Channels 

2 

1.544  Mbps  (xl) 

256  Kbps  (xl) 

512  Kbps  (x2) 

4 

1.544  Mbps  (xl) 

512  Kbps  (xl) 

256  Kbps  (xl) 

512  Kbps  (x2) 

256  Kbps  (x2) 

8 

1.544  Mbps  (x2) 

512  Kbps  (x2) 

256  Kbps  (x2) 

128  Kbps  (xl) 

64  Kbps  (xl) 

512  Kbps  (x4) 

256  Kbps  (x4) 

20 

1.544  Mbps  (x3) 

512  Kbps  (x2) 

256  Kbps  (x4) 

128  Kbps  (x4) 

64  Kbps  (x7) 

512  Kbps  (x6) 

256  Kbps  (x8) 

128  Kbps  (x6) 

Table  XIII.  BADD  Channel  Allocations  for  Various  Channel  Configurations. 

data  sets.  Table  XV  shows  the  various  mixes  of  application  types  that  we  used  in 
these  simulations.  In  our  smaller  tests,  as  well  as  with  our  larger  tests,  we  wajited 
a  mix  of  applications  that  would  be  representative  of  those  that  we  would  expect  to 
see  sent  over  the  BADD  network.  The  values  in  the  table  were  loosely  based  upon 
those  used  in  Joint  Task  Force  (JTF)  Advanced  Technology  Demonstration  (ATD) 
experiment  in  1995  [Ref.  19].  After  completing  simulations  on  the  smaller  data  sets, 
we  used  exactly  the  same  data  as  that  used  in  the  JTF  ATD  experiment  as  shown  in 
Table  XVI.  Table  XVII  shows  the  mix  of  requesters  we  used  for  our  heterogeneous 
and  homogeneous  runs.  Below  we  expand  upon  the  sizes  of  messages  generated  by 
the  various  JTF  ATD  applications. 

1.  Database  Views  (DB)  -  The  mean  of  message  sizes  is  1  Mbyte.  We  used  both 
this  value  and  smaller  value  of  500  Kbytes  with  a  constant  distribution. 

2.  Email  -  Ranged  from  100  bytes  for  text  only  systems  to  1  Mbyte  systems 
capable  of  handling  graphical  attachments.  We  selected  values  of  1  Mbyte,  250 
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Kbytes,  and  500  bytes  to  represent  these  ranges  using  a  constant  distribution. 

3.  Web  Masters  -  Ranged  from  500  bytes  to  50  Kbytes.  We  selected  values  of 
1  Kbyte  and  50  Kbytes  to  represent  this  range.  Again  we  used  a  constant 
distribution  to  generate  these  packets  in  our  simulation. 

4.  Video  -  This  value  did  not  come  from  the  JTF  ATD  experiment.  We  calculated 
this  value  based  upon  a  UAV  transmission  rate  of  64Kbps.  We  assumed  that 
a  commander  would  be  interested  in  the  UAV’s  flight  over  his  area  of  interest 
and  that  the  time  required  for  fly  over  would  be  2  minutes.  Based  upon  this 
time  constraint,  and  the  data  rate  the  UAV  sends  data  to  the  ground  station, 
we  calculated  the  size  of  1  MByte  for  this  message  (message  size  =  64Kbps  * 
60  seconds  *  2  minutes  * 


Data  Source 

Wait 

Call  Size 

BPS  Production  Rate 

Large  DB  View 

1.0 

338  Kbytes 

1.35M 

Video 

0.2 

135  Kbytes 

l.OM 

Large  Email 

0.1 

63  Kbytes 

507K 

Large  Web 

0.5 

32  Kbytes 

256K 

Small  DB  View 

0.001 

206  bytes 

165K 

Medium  Email 

0.01 

16  Kbytes 

126K 

Small  Web 

0.01 

9.9  Kbytes 

79K 

Small  Email 

0.0011 

675  bytes 

54K 

Table  XIV.  Representative  Simulation  Data  Sources 


We  now  discuss  our  choice  of  homogeneous  and  heterogeneous  mix  of  data 
sources  in  more  detail.  We  use  the  term  homogeneous  to  mean  that  calls  generated  by 
the  data  sources  have  similar  bit  production  rates.  A  heterogeneous  mix  means  that 
there  is  more  variety  in  these  production  rates.  An  example  of  a  heterogeneous  set  of 
sources  that  we  used  had  one  1.581  Mbps  source,  one  501.894  Kbps  source,  one  250.95 
Kbps  source,  and  one  65.34  Kbps  source.  A  homogeneous  set  of  4  sources  consisted 
of  two  501.894  Kbps  sources  and  two  250.95  Kbps  sources. 


109 


Number  of  Requesters 
Allocated 

Heterogeneous 

Mix  of  Requesters 

Homogeneous 

Mix  of  Requesters 

2 

Large  DB  Views  (xl) 
Small  Email  (xl) 

Large  Email  (x2) 

4 

Large  DB  View  (xl) 
Large  Email  (xl) 

Small  DB  Views  (xl) 
Small  Email  (xl) 

Large  Email  (x2) 

Large  Web  (x2) 

8 

Large  DB  View  (xl) 
Video  (xl) 

Large  Email  (xl) 

Large  Web  (xl) 

Small  DB  View  (xl) 
Medium  Email  (xl) 
Small  Web  (xl) 

Small  Email  (xl) 

Large  Email  (x4) 

Large  Web  (x4) 

Table  XV.  Requester  Configurations  for  Testing  Small  Data  Sets 

B.  RESULTS 

In  Figure  53  we  provide  the  results  of  our  testing  for  both  of  the  schedulers 
using  small  data  sets.  The  column  label  indicates  the  runtimes  of  our  simulations  in 
seconds.  The  row  labels  indicate  the  configuration  of  the  requesters  and  the  number  of 
servicing  channels.  The  rows  are  each,  divided  into  sub-rows.  The  top  entry  for  each 


Data  Source 

Wait 

Call  Size 

BPS  Production  Rate 

Large  DB  Views 

0.0007 

1.0  Mbytes 

1.58"iM 

Large  Email 

0.0022 

1.0  Mbytes 

501.894K 

2  Min  Video 

0.0007 

1.0  Mbytes 

1.581M 

Small  DB  Views 

0.0022 

500  Kbytes 

501.894K 

Medium  Email 

0.0044 

250  Kbytes 

250.95K 

Large  Web  View 

0.009 

50  Kbytes 

12i69K 

Small  Web  View 

0.0169 

1  Kbytes 

65.34K 

Small  Email 

0.0169 

500  bytes 

65.34K 

Table  XVI.  Realistic  Simulation  Data  Sources  (Derived  From  [Ref.  19]). 
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Number  of  Requesters 
Allocated 

Heterogeneous 

Mix  of  Requesters 

Homogeneous 

Mix  of  Requesters 

16 

Large  DB  Views  (x2) 
Large  Email  (x2) 

2  Min  Video  (x2) 

Small  DB  Views  (x2) 
Medium  Email  (x2) 
Large  Web  View  (x2) 
Small  Web  View  (x2) 
Small  Email  (x2) 

Small  DB  Views  (x4) 
Medium  Email  (x8) 
Large  Web  View  (x4) 

Table  XVII.  Channel  Allocations  for  16  Requester  Configurations. 

sub-row  is  the  average  bit  throughput.  The  bottom  entry  is  the  completion  time  of 
the  last  scheduled  transmission  if  all  transmissions  are  allowed  to  run  to  completion. 
Note  that  we  also  simultaneously  vary  the  mix  of  the  data  requesters  and  channels  as 
depicted  by  the  partitioning  of  the  columns. 

We  provide  the  results  of  our  testing  for  the  realistically  sized  data  in  Figure  54 
in  the  same  format  as  Figure  53.  We  eliminated  the  10  and  25  second  runtimes  because 
they  do  not  provide  any  new  data.  (Instead,  we  looked  at  varying  the  input  from  the 
requesters  from  a  constant  distribution  to  an  exponential  distribution.)  In  the  next 
section  we  provide  the  analysis  of  these  results. 


C.  ANALYSIS  OF  RESULTS 

This  section  provides  the  analysis  of  testing  that  allowed  us  to  make  certain 
conclusions  about  the  nature  of  the  BADD  architecture  with  different  schedulers. 

1.  Effects  of  Satellite  Delay  on  ATM  Protocol 

OPNET  provides  direct  support  for  modeling  duplex  ATM  networks.  Earlier 
we  described  how  we  modified  these  models  to  approximate  BADD’s  simplex  ATM 
protocol.  These  models  allow  the  user  to  insert  delays,  which  are  normally  small, 
between  ATM  switches.  However,  since  the  BADD  architecture  uses  a  Global  Broad- 
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Figure  53.  Representative  Test  Results 
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Heterogeneous  Homogeneous  Heterogeneous  Homogeneov 
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GREEDY  FIFO 

Run  Duration  (seconds)  Run  Duration  (seconds) 


Constant 


Exponential 


Figure  54.  Realistic  Test  Results 

cast  Satellite  (GBS)  satellite  in  geosynchronous  orbit,  we  must  use  a  fairly  large  delay 
of  0.250  seconds,  which  is  more  typical  of  geosynchronous  satellite  propagation  [Ref. 
6]. 

For  comparison,  we  did  execute  the  original  OPNET  dynamic  virtual  channel 
duplex  protocol  using  the  0.25  second  delay.  Our  first  observation  is  that  the  duplex 
ATM  protocol  is  not  efficient  when  using  links  with  large  delays  because  of  the  setup 
signaling  requirements  in  the  protocol.  Figure  55  shows  that  the  these  requirements 
require  the  channel  to  be  idle  for  large  periods  of  time  while  awaiting  responses  to 
establish  and  terminate  call  setups.  This  idle  time  clearly  reduces  the  amount  of 
data  transmitted  over  the  network  and  lowers  the  bit  throughput  rate.  Therefore  we 
conclude  that  although  the  BADD  designers  chose  a  simplex  implementation  for  a 
different  reason,  a  duplex  implementation  for  a  BADD-like  architectures  should  never 
be  considered  due  to  the  low  bit  throughput  rate  caused  by  the  combination  of  large 
propagation  delays  with  dynamic  virtual  channels. 

We  see  two  areas  that  are  worthy  of  further  investigation.  One  is  the  incor¬ 
poration  into  OPNET  of  a  simplex  ATM  protocol.  The  second  is  an  investigation  of 
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Figure  55.  Effects  of  Large  Delay  on  Link  Utilization 


the  use  of  Low  Earth  Orbit  (LEO)  satellites  rather  than  geosynchronous  satellites  in 
BADD.  The  use  of  LEO  satellites  would  require  modification  of  the  protocol  because 
the  LEO  satellite  is  moving;  however,  the  propagation  delays  would  be  significantly 
decreased  to  approximately  .005  seconds,  a  value  from  the  planned  Teledesic  Satellite 
System  orbiting  between  695  and  705  kilometers  [Ref.  20]. 

2.  Effects  of  Varying  Simulation  Parameters 

Our  experimental  results  shown  above  indicate  that  scheduler  performance  was 
independent  of 

1.  the  number  of  sources, 

2.  the  number  of  calls,  and 

3.  the  duration  of  our  simulation. 

However  it  depends  heavily  on  the  heterogeneity  of  both  the  sources  and  the 
channels.  We  found  that  the  FIFO  algorithm  occcisionally  outperforms  the  Greedy 
algorithm  with  simulations  run  with  homogeneous  sources  and  channels,  that  is  when 
the  bandwidth  requirements  of  the  sources  were  nearly  identical  to  each  other  as  well 
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as  the  capability  of  the  channels.  However,  in  all  other  cases  the  Greedy  scheduler 
provides  a  better  schedule.  In  the  following  subsections,  we  provide  results  of  simula¬ 
tions  with  the  16  requesters  and  the  20  channels  defined  in  the  previous  section. 

a.  Completion  Time  Observations 

Using  the  multiple  sources  shown  in  Table  XVII,  we  found  that  the 
total  channel  utilization  using  either  the  Greedy  or  FIFO  scheduler  is  approximately 
the  same.  Figure  56  compares  the  completion  times  of  channels  using  both  the  Greedy 
and  FIFO  schedulers.  While  the  average  channel  completion  time  using  either  of  these 
schedulers  is  approximately  72  seconds,  the  Greedy  scheduler  provides  a  much  more 
uniform  set  of  completion  times.  When  evaluating  the  worst  completion  times  of 
the  schedules,  we  find  that  Greedy’s  worst  completion  time  is  92.79  seconds  whereas 
FIFO’s  worst  time  is  174.42  seconds.  The  worst  FIFO  channel  takes  88  percent  longer 
than  the  worst  Greedy  channel. 


Figure  56.  Greedy  vs.  FIFO  Channel  Completion  Times  for  Heterogeneous  Sources 
and  Channels 

To  help  explain  these  results.  Figure  57  shows  the  Estimated  Time  of 
Completion  (ETC)  Matrix  that  provides  the  key  reason  why  both  schedulers  have  the 
same  average  completion  time.  When  our  requester  generates  a  call,  the  first  step  is 
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Figure  57.  Estimated  Time  of  Completion  Matrix 

to  determine  which  channels  can  support  the  transmission.  In  our  ETC  matrix  we 
display  some  empty  entries.  These  empty  entries  are  result  of  the  channels  inability 
to  support  the  traffic  and  need  not  be  evaluated  by  the  scheduler.  We  also  notice  that 
each  call  requires  the  same  amount  of  time  on  each  virtual  channel.  The  reason  why 
all  VCs  have  the  same  value  for  a  given  call  is  because  we  considered  only  one  signaling 
characteristic,  transmission  rate.  When  other  characteristics  such  as  bit  error  rate  are 
taken  into  consideration  we  would  not  see  the  same  values  in  all  supporting  VCs  for 
a  particular  call.  Our  implementation,  with  the  same  estimated  completion  values  for 
each  call,  independent  of  VC,  causes  both  schedulers  to  have  the  same  finishing  times 
because  the  number  of  calls  requested  are  the  same  and  the  servicing  times  for  the  calls 
are  the  same.  In  other  words,  even  though  the  schedulers  place  the  calls  on  different 
channels,  the  aggregate  time  to  run  the  calls  will  be  the  same  for  both  schedulers. 
b.  Bit  Throughput  Observations 

Using  a  heterogeneous  set  of  sources  we  foimd  that  the  use  of  the  Greedy 
algorithrh  yields  better  bit  throughput  than  the  use  of  the  FIFO  algorithm.  Figures  58 
and  59  show  that  the  bit  throughput  for  Greedy  averages  approximately  5.4  Mbps 
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while  FIFO’s  bit  throughput  averages  approximately  3.7  Mbps.  These  results  show 
a  46  percent  greater  average  bit  throughput  for  a  representative  set  of  sources  and 
channels. 

c.  Calls  Scheduled  vs  Calls  Completed 
Figures  60  and  61  show  a  distribution  diagram  of  the  number  of  calls 
scheduled  (dashed  lines)  vs.  the  number  of  calls  completed  on  each  of  the  channels 
(solid  lines).  We  see  that  the  number  of  calls  scheduled  for  each  channel  is  much 
more  uniform  for  the  FIFO  Algorithm.  This  demonstrates  an  innate  failure  of  the 
FIFO  algorithm  in  that  it  assigns  calls  to  channels  based  only  upon  the  number  of 
calls  scheduled.  FIFO  does  not  consider  the  length  of  the  calls,  but  only  that  the 
number  of  calls  are  evenly  split  between  channels.  We  also  observe  that  the  average 
difference  in  the  number  of  calls  scheduled  versus  the  number  of  calls  completed  is 
approximately  the  same  for  both  algorithms,  approximately  42  for  our  representative 
run.  The  difference  between  the  algorithms  is  that  the  variance  of  this  difference 
is  much  higher  for  the  Greedy  algorithm.  This  observation  makes  sense  because  the 
Greedy  algorithm  does  not  attempt  to  balance  the  number  of  calls,  but  rather  attempts 
to  minimize  the  completion  times. 

3.  OPNET  Observations  and  Recommendations 

OPNET  is  an  extremely  powerful  network  simulation  tool.  We  found  their 
libraries  useful  in  modifying  bur  network  and  are  grateful  that  all  of  their  source  code 
is  provided.  We  found  that  once  our  basic  model  was  developed,  that  it  was  very 
easy  to  modify  with  the  GUI.  We  also  appreciated  that  a  discrete  event  simulator, 
supporting  different  distributions,  was  already  present  as  well  as  an  analysis  tool 
that  graphed  output  with  little  effort  from  the  user.  Clearly  OPNET  is  a  quality 
networking  tool.  However,  there  are  challenges  in  using  state-of-the-art  products  to 
model  next  generation  networks.  In  this  section  we  will  highlight  some  of  the  lessons 
we  learned  and  provide  recommendations  for  OPNET  and  other  modeling  tools. 

The  approach  taken  in  BADD  is  to  keep  things  simple  at  first  and  then  incre- 
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Figure  58.  Greedy  Bit  Throughput  for  Heterogeneous  Sources  and  Channels 


Figure  59.  FIFO  Bit  Throughput  for  Heterogeneous  Sources  and  Channels 
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Figure  60.  Greedy  Algorithm:  Calls  Scheduled  vs.  Calls  Completed  for  Heterogeneous 
Sources  and  Channels 


Figure  61.  FIFO  Algorithm:  Calls  Scheduled  vs.  Calls  Completed  for  Heterogeneous 
Sources  and  Channels 
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mentally  improve  the  features  of  the  architecture  as  the  users  become  more  comfortable 
with  the  equipment  and  as  industry  establishes  more  robust  capabilities  in  the  com¬ 
mercial  market.  Therefore,  the  BADD  network  simplifies  the  ATM  architecture  by 
stripping  out  much  of  the  functionality  of  ATM.  OPNET’s  models  are  based  on  using 
most  of  the  functionalities  defined  in  the  standard  duplex  ATM  protocol.  Because  of 
BADD’s  design  decision  to  use  static  virtual  channels  on  simplex  links  we  were  forced 
to  greatly  modify  the  OPNET  code  and  support  utilities. 

At  first  we  found  it  difficult  to  design  our  network  using  their  standard  models 
because  they  difllered  substantially  from  BADD.  The  tutorials  had  given  us  a  false 
sense  of  security  and  we  began  our  design  with  the  intent  of  making  modest  changes 
to  the  duplex  implementation.  As  we  became  more  familiar  with  the  tool,  we  recog¬ 
nized  that  we  would  have  to  rewrite  the  OPNET  code  for  setup  and  tear  down  of 
dynamic  virtual  paths  and  virtual  channels.  Below  we  enumerate  some  of  the  lessons 
learned  from  our  simulation  design,  provide  our  observations  for  future  users,  and 
offer  suggestions  for  additional  features  we  would  like  to  see  OPNET  provide  in  the 
future. 

OPNET  requires  the  commitment  of  a  large  amount  of  time  before  the  user 
will  feel  comfortable  using  the  tools  for  advanced  research.  With  no  training,  a  vast 
amount  of  our  design  time  was  spent  developing  a  basic  working  network  model.  In 
order  to  gain  maximum  benefit  from  this  simulation  tool,  the  user  should  have  a 
thorough  understanding  of  the  network  and  the  associated  protocols  used  within  it. 
We  recommend  the  user  read  the  following  portions  of  the  OPNET  manuals  in  the 
order  we  specify. 

1.  Complete  the  Introduction  to  OPNET  Tutorial,  Basic  Model  Tutorial  and  one 
other  tutorial  to  get  a  feel  for  OPNET. 

2.  Read  the  first  Modeling  Manual  in  detail  on  the  Modeling  Overview,  Modeling 
Framework,  and  Process  Domain  Definitions. 

3.  Read  the  particular  section  on  the  model  or  protocol  that  the  user  is  interested 
in  modeling. 


If  we  had  carefully  read  these  sections  in  the  above  order,  we  would  have  saved  a 
month  of  our  time  learning  the  tool.  We  continually  found  ourselves  going  back  to 
these  sections  to  refresh  our  imderstanding  of  how  OPNET  worked. 

Below  we  make  some  suggestions  for  enhancing  OPNET  to  make  it  more  useful 
for  tomorrow’s  network  designers.  We  separate  our  suggestions  into  major  and  minor 
categories. 

а.  Major  Enhancements  Recommended  for  OPNET 

1.  MIL  3  should  consider  providing  packet  generators  and  queue  models  at  the 
process  and  node  level.  Currently,  OPNET  implements  numerous  functions, 
such  as  packet  generators  and  queues,  only  at  the  node  level.  During  our 
design,  we  required  these  functions  at  the  process  level  which  forced  us  to 
write  these  functions  as  processes  within  our  model. 

2.  We  believe  that  simplex  ATM,  particularly  when  used  in  conjunction  with 
geosynchronous  satellite  broadcast,  will  be  an  important  protocol  of  the  future. 
We  therefore  believe  that  MIL  3  should  consider  providing  a  simplex  ATM 
protocol. 

3.  Running  OPNET  simulations  from  the  command  line  is  neither  intuitive  nor 
user  friendly.  During  our  model  development,  our  system’s  administrator  up¬ 
graded  the  operating  system  and  we  lost  access  to  the  OPNET  Graphical  User 
Interface  for  three  weeks.  The  External  Interfaces  Manual  describes  only  basic 
command  line  syntax  and  the  command  line  options  are  spread  over  several 
different  chapters  in  the  manual.  Giving  the  command  line  syntax  with  all 
available  options  in  one  section  would  drastically  improve  the  usefulness  of  the 
manual. 

4.  MIL  3  should  consider  providing  a  GUI  utility  to  allow  the  user  to  save  simula¬ 
tion  runs,  enabled  with  traces,  to  a  file  for  further  analysis.  We  needed  to  run 
self-produced  scripts  from  the  command  line  in  order  to  save  data  into  scripts 
for  analysis.  Some  operations  required  invocation  of  debug  operations  in  order 
to  capture  the  status  of  data  throughout  the  simulation. 

б.  Minor  Enhancements  Recommended  for  OPNET 

1.  We  recommend  that  MIL  3  look  at  reimplementing  their  code  to  calculate  the 
Peak  Cell  Rate  (PGR)  in  the  ams_traf_gen  process  as  floating  point  division. 
The  current  implementation  does  integer  division.  Subsequently  a  conditional 
checks  the  value  of  the  PGR  and  assigns  the  value  of  1  to  all  calculations  less 
than  one. 
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2.  We  were  constrained  by  OPNET’s  limitations  on  the  numbers  of  requesters 
that  can  be  fed  into  the  AAL  module.  OPNET  should  provide  a  method,  at 
the  module  level,  that  allows  the  modeler  to  include  large  numbers  of  data 
generators  into  the  AAL  module. 

4.  Parallelization  of  Scheduling  Algorithms 

We  examined  the  possibility  of  using  parallel  processors  to  improve  the  speedup 
of  our  scheduling  algorithms.  These  efforts  were  done  independent  of  our  OPNET 
simulation. 

We  used  a  Silicon  Graphics  Challenge,  with  four  processors  to  parallelize  our 
Greedy  code.  Table  XVIII  shows  the  time  in  seconds  to  complete  scheduling  based 
on  the  number  of  calls.  The  speedup  calculations  are  based  upon  the  runtime  of  the 
C  code  on  one  processor  against  the  runtime  of  the  C  code  on  all  4  processors. 


Calls 

Channels 

Seq(C) 

Para(C) 

Speedup 

20 

16 

0.104 

0.542 

0.19 

100 

16 

0.12 

0.604 

0.20 

1000 

16 

2.967 

4.318 

0.69 

10000 

16 

287.053 

364.829 

0.79 

20000 

16 

1447.164 

1567.002 

0.92 

30000 

16 

2587.132 

2314.182 

1.12 

40000 

16 

4584.385 

3738.235 

1.23 

Table  XVIII.  SGI  Speedup  Calculations 
[SGI  Speedup  Calculations,  all  times  are  given  in  microseconds.] 


D.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 
1.  Optimal  Scheduling  Times 

OPNET  discrete  event  simulations  service  events  under  the  assumption  that 
they  take  no  time  to  execute.  This  is  necessary  to  support  the  overhead  of  running 
a  simulation.  A  side  effect  of  this  design  is  that  calls  to  our  scheduling  algorithms 
do  not  require  any  simulation  time.  This  is  clearly  not  realistic.  We  investigated 
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incorporating  the  run  times  into  our  schedulers,  independent  of  the  simulation,  to  gain 
some  understanding  of  how  much  time  it  takes  to  run  the  scheduling  algorithms.  We 
found  that  the  runtime  of  the  algorithm  was  proportional  to  size  of  squaring  our  input 
to  the  algorithm.  We  used  this  rough  estimate  to  calculate  a  delay  for  scheduling 
but  did  not  include  this  modification  in  the  simulation  due  to  time  constraints.  The 
inclusion  of  this  modification  is  absolutely  necessary  to  perform  a  cost-benefit  analysis 
of  integrating  the  scheduling.  It  is  also  necessary  in  determining  the  optimal  time  to 
wait  before  calling  the  scheduler. 

2.  Implementation  with  Static  Virtual  Paths  vs.  Static 
Virtual  Channels 

We  recommend  that  simulation  of  the  BADD  network  be  modeled  with  static 
virtual  paths  rather  than  static  virtual  channels.  This  model  would  be  more  natural 
to  the  OPNET  ATM  protocols  and  would  preserve  the  flexibility  of  dynamic  virtual 
channel  allocation  within  the  static  virtual  paths.  The  preservation  of  dynamic  alloc¬ 
ation  would  provide  flexibility  for  schedules  to  use  the  large  bandwidth  paths  to  send 
multiple  small  calls  when  they  are  not  sending  large  calls  over  the  path. 

3.  Inclusion  of  Attributes  in  Scheduling  Algorithm 

Our  current  scheduler  makes  its  decisions  based  upon  completion  time  only. 
A  better  implementation  would  include  considerations  for  other  attributes  such  as 
bit  error  rate  and  jitter  characteristics  of  the  various  channels.  A  more  comprehens¬ 
ive  scheduler  could  accomplish  this  by  applying  weighting  factors  for  each  desired 
attribute. 

E.  SUMMARY 

The  use  of  OPNET  to  model  communication  networks  is  highly  advantageous 
because  it  provides  an  extensive  array  of  tools  to  support  simulation  development 
and  analysis.  When  developing  new  protocols  there  is  significant  time  required  to 
understand  the  complexities  of  OPNET  before  the  user  can  achieve  their  desired 
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modeling  results. 

The  use  of  the  C)(n^m)  Greedy  algorithm  will  decrease  the  time  required  to 
completely  process  all  calls.  Our  results  indicate  that  the  BADD  program  should 
consider  integrating  this  algorithm  into  their  current  architecture  in  order  to  increase 
the  performance  of  the  network. 
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APPENDIX  A.  ABBREVIATIONS  AND 
DEFINITIONS 

The  following  listing  of  abbreviations  and  definitions  includes  an  abridged 
and  extended  version  of  Cisco  Internetworking  Terms  and  Acronyms.  The  abridge¬ 
ment  is  based  on  terms  used  in  this  thesis.  The  original  glossary  can  be  found  at 
http :  / /www.erl.noaa.gov  /  noc /cisco  /  data/ doc/ cintrnet  /  ita.htm 


•  ACK  Flag.  A  bit  that,  when  set,  alerts  the  protocol  that  the  acknowledgment 
number  is  valid. 

•  ACTD  Advanced  Concepts  Technology  Demonstration. 

•  AHPCA  Advanced  High  Performance  Computing  Applications. 

•  Address  Translation.  The  process  of  converting  external  addresses  into 
standardized  network  addresses  and  vice  versa.  It  facilitates  the  interconnec¬ 
tion  of  multiple  networks  in  which  each  have  their  own  addressing  scheme. 

•  Analog  A  type  of  transmission  in  which  a  continuously  variable  signal  encodes 
an  infinite  number  of  values  for  the  information  being  sent.  (Compare  with 
“digital”) 

•  ANSI  The  American  National  Standards  Institute  is  a  US-based  organization 
that  develops  standards  and  defines  interfaces  for  telecommunications  systems. 

•  ABCS  Army  Battle.  Command  System. 

•  Asynchronous  A  term  used  to  describe  any  transmission  technique  that  does 
not  require  a  common  clock  between  the  two  communicating  devices,  but  in¬ 
stead  derives  timing  signals  from  special  bits  or  characters  (i.e.,  start /stop  bits, 
flag  characters)  in  the  data  stream  itself.  (Compare  with  “synchronous.”) 

•  Asynchronous  Transfer  Mode  (ATM)  A  form  of  digital  transmission  based 
on  the  transfer  of  units  of  information  known  as  cells.  It  is  suitable  for  the 
transmission  of  image,  voice,  video,  and  data. 

•  ATM  Asynchronous  Transfer  Mode. 
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•  ATM  Adaptation  Layer  (AAL)  The  AAL  translates  digital  voice,  image, 
video,  and  data  signals  into  the  ATM  cell  format  and  vice  versa.  Five  AALs 
are  defined: 

—  AALl  supports  connection-oriented  services  needing  constant  bit  rates 
and  specific  timing  and  delay  requirements,  (e.g.,  DS-3  circuit) 

—  AAL2  supports  connection-oriented  services  needing  variable  bit  rates, 
(e.g.,  certain  video  transmission  schemes) 

-  AAL3/4  supports  both  connectionless  and  connection-oriented  variable 
rate  services. 

—  AALS  supports  connection-oriented  variable  bit  rate  data  services.  AKA: 
Simple  and  Efficient  Adaptation  Layer  (SEAL) 

•  ATM  Application  Program  Interface  (API)  While  no  standard  ATM  API 
exists,  the  ATM  Forum  is  developing  an  API  that  enables  application  developers 
to  use  ATM’s  quality  of  service  and  traffic  management  features.  In  the  mean¬ 
time,  FORE  Systems  is  one  the  vendors  that  supply  an  API  library  with  its 
line  of  ATM  network  adapter  cards.  Services  such  as  guaranteed  bandwidth 
reservation,  per  connection  selection  of  AAL5  or  AAL3/4,  and  multicasting 
with  dynamic  addition  and  deletion  of  recipients  axe  made  available  to  the  ap¬ 
plication.  Applications  that  use  FORE’s  ATM  API  bypass  inefficiencies  and 
overhead  associated  with  typical  TCP /IP  protocol  stacks. 

•  ATM  Layer  The  protocol  layer  that  relays  cells  from  one  ATM  node  to  an¬ 
other.  It  handles  most  of  the  processing  and  routing  activities  including:  each 
cell’s  ATM  header,  cell  muxing/demuxing,  header  validation,  payload-type 
identification,  quality-of-service  specification,  prioritization,  and  flow  control. 

•  Available  Bit  Rate  (ABR)  A  type  of  traffic  for  which  the  ATM  network 
attempts  to  meet  that  traffic’s  bandwidth  requirements.  It  does  not  guaran¬ 
tee  a  specific  amount  of  bandwidth  and  the  end  station  must  retransmit  any 
information  that  did  not  reach  the  far  end. 

•  BADD  Battlefield  Awarness  and  Data  Dissemination. 

•  BC2A  Bosnia  Command  and  Control  Augmentation  Initiative. 

•  Bandwidth  A  measure  of  capacity,  usually,  the  capacity  of  a  communica¬ 
tions  line  to  transmit  voice,  data,  video,  or  image  traffic  through  a  network. 
Bandwidth  is  usually  expressed  in  bits  per  second  (bps),  thousands  of  bits  per 
second  (kbps),  millions  of  bits  per  second  (Mbps),  or  billions  of  bits  per  second 
(Gbps). 
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•  Border  Gateway  Protocol  (BGP)  A  protocol  used  by  gateway  devices  (e.g., 
routers)  in  an  internetwork,  connecting  autonomous  networks.  Based  on  the 
exterior  gateway  protocol. 

•  Broadband  A  service  or  system  requiring  transmission  channels  capable  of 
supporting  rates  greater  than  the  Integrated  Services  Digital  Network  (ISDN) 
primary  rate  (1.544  Mbps). 

•  Broadcast  (Messages)  Transmissions  sent  to  all  stations  (or  nodes,  or  devices) 
attached  to  the  network. 

•  BMC  Broadcast  Management  Center. 

•  Broadcast  and  Unknown  Server  (BUS)  In  LAN  Emulation,  a  LAN  Emu¬ 
lation  server  provides  address  resolution  between  LAN  addresses  and  ATM 
network  addresses.  Multicast  traffic  and  unknown  traffic  (i.e.,  any  data  for 
which  the  sender  has  not  obtained  an  ATM  address)  require  dilferent  proced¬ 
ures  and  are  handled  by  the  broadcast  and  unknown  server. 

•  Buffer  An  area  of  storage  that  provides  an  tminterrupted  flow  of  data  between 
two  computing  devices. 

•  CCITT  The  Consultative  Committee  on  International  Telephony  and  Tele¬ 
graphy,  now  the  International  Telecommunications  Union  (ITU),  is  an  interna¬ 
tional  organization  that  develops  standards  and  defines  interfaces  for  telecom¬ 
munications  systems. 

•  CNN  Cable  News  Network. 

•  Cell  A  transmission  unit  of  fixed  length  used  in  cell  relay  transmission  tech¬ 
niques  such  as  ATM.  An  ATM  cell  is  made  up  of  53  bytes  (octets)  including  a 
5-byte  header  and  a  48-byte  data  payload. 

•  Cell  Delay  Variation  (CVD)  A  measurement  of  the  allowable  variation  in 
delay  between  the  reception  of  one  cell  and  the  next.  (Usually  expressed  in 
thousandths  of  a  second,  or  milliseconds  (msec.).  Important  in  the  transmission 
of  voice  and  video  traffic,  CDV  measurements  determine  whether  or  not  cells 
are  arriving  at  the  far  end  too  late  to  reconstruct  a  valid  packet. 

•  Cell  Relay  Any  transmission  technique  that  uses  packets  of  a  fixed  length. 
ATM,  for  example,  is  a  version  of  cell  relay  using  53-byte  cells.  Other  versions 
use  cells  of  a  different  length. 

•  Cell  Loss  Priority  (CLP)  A  bit  in  the  ATM  cell  header  that  indicates  the 
cell’s  transmission  priority.  If  the  bit  is  set  (value=l),  the  cell  is  eligible  to  be 
discarded,  if  it  is  not  (value=0),  it  cannot  be  discarded. 
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•  Circuit  Switching  A  switching  technique  in  which  a  dedicated  path  is  set  up 
between  the  transmitting  device  and  the  receiving  device,  remaining  in  place 
for  the  duration  of  the  connection,  (e.g.,  a  plain  old  telephone  call  is  a  circuit- 
switched  connection) 

•  Common  Part  Convergence  Sublayer  (CPCS)  The  part  of  an  ATM  ad¬ 
aptation  layer’s  convergence  sublayer  that  does  not  vary  with  the  type  of  traffic 
being  sent. 

•  Connection  Admission  Control  (CAC)  Methods  used  to  control  the  set  up 
of  switched  virtual  circuits.  For  example,  one  method  is  known  as  overbooking 
and  assumes  that  active  connections  are  not  using  all  of  the  available  band¬ 
width.  Another  method,  known  as  full  booking,  limits  network  access  once 
all  bandwidth  is  committed.  Only  connections  that  request  acceptable  traffic 
parameters  are  permitted. 

•  Connection-oriented  A  type  of  communication  in  which  an  assigned  path 
must  exist  between  a  sender  and  a  receiver  before  a  transmission  occurs,  (e.g., 
circuit  switching)  ATM  networks  are  connection-oriented. 

•  Connectionless  A  type  of  communication  in  which  no  fixed  path  exists  between 
a  sender  and  receiver,  even  during  a  transmission,  (e.g.,  packet  switching) 
Shared  media  LANs  are  connectionless. 

•  COTS  commercial  off-the-shelf. 

•  Constant  Bit  Rate  (CBR)  A  type  of  traffic  that  requires  a  continuous,  spe¬ 
cific  amount  of  bandwidth  over  the  ATM  network  (e.g.,  digital  information  such 
as  video  and  digitized  voice). 

•  C4I  Command,  Control,  Computer,  and  Intelligence. 

•  Digital  A  type  of  transmission  that  encodes  a  discrete  value  (e.g.,  “0”  or  “1”) 
for  each  unit  of  information  being  encoded.  (Compare  with  “analog.”) 

•  DARPA  Defense  Advanced  Research  and  Project  Agency. 

•  DIA  Defense  Intelligence  Agency. 

•  DIM  Downlink  Information  Manager. 

•  DISN  LES  Defense  Information  Systems  Network  Leading  Edge  Services. 

•  DMA  Defense  Mapping  Agency. 

•  DoD  Department  of  Defense. 
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•  Dual  Leaky  Buckets  A  method  employed  by  ATM  switches  to  perform  flow 
control  (traffic  policing)  on  ATM  network  connections.  Hardware  in  the  switch 
monitors  each  connection  to  determine  whether  it  has  exceeded  its  negotiated 
rate.  Dual  leaky  buckets  refers  to  the  use  of  one  “bucket”  to  monitor  the 
average  or  sustained  rate  and  one  to  monitor  the  peak  rate. 

•  EPLRS  VHSIC  Enhanced  Position  Location  Reporting  System  Very  High 
Speed  Integrated  Circuit. 

•  FIFO  First  In  First  Out. 

•  FIN  Flag.  This  bit  is  set  when  either  the  sender  or  receiver  finishes  with  a 
connection. 

•  Frame  Variable  length  packet  of  data  used  by  traditional  LANs  such  as  Eth¬ 
ernet  and  Token  Ring  cis  well  as  WAN  services  such  as  X.25  or  Frame  Relay. 
An  edge  switch  will  take  frames  and  divide  them  into  fixed-length  cells  using 
an  AAL  format.  A  destination  edge  switch  will  take  the  cells  and  reconstitute 
them  into  frames  for  final  delivery. 

•  GBS  Global  Broadcast  System. 

•  Generic  Flow  Control  (GFC)  The  first  four  bits  of  the  ATM  UNI  cell  header; 
used  when  passing  cells  to/from  the  UNI.  Setting  any  of  the  bits  in  this  field 
indicates  to  the  end  station  that  the  ATM  switch  can  implement  some  form  of 
congestion  control. 

•  Gigabits  Per  Second  (Gbps)  A  digital  transmission  speed  of  billions  of  bits 
per  second. 

•  GUI  Graphical  User  Interface. 

•  Header  Error  Control  (HEC)  An  8-bit  Cyclic  Redundancy  Code  (CRC) 
computed  on  all  fields  in  an  ATM  header;  capable  of  detecting  single  bit  and 
certain  multiple  bit  errors.  HEC  is  used  by  the  Physical  Layer  for  cell  delin¬ 
eation. 

•  HMMWV  High  Mobility  Military  Wheeled  Vehicle, 

•  ICI  Interface  Control  Information.  Used  by  OPNET  processes. 

•  IDS  Information  Dissemination  Server. 

•  IMETS  Integrated  Meteorological  System. 

•  IRD  Integrated  Receiver  Decoders. 
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•  ISO  International  Standards  Organization. 

•  1ST  Integrated  Systems  Technology. 

•  ITU-T  International  Telecommunication  Union  Telecommunication  Standard¬ 
ization  Sector. 

•  Internet  Protocol  (IP)  Address  An  identifier  for  a  network  node;  expressed 
as  four  fields  separated  by  decimal  points  (e.g.,  136.19.0.5.);  IP  address  is  site- 
dependent  and  assigned  by  a  network  administrator. 

•  IP  -over- ATM  The  adaptation  of  TCP/IP  and  its  address  resolution  protocol 
for  transmission  over  an  ATM  network.  It  is  defined  by  the  IETF  in  RFCs 
1483  and  1577.  It  puts  IP  packets  and  ARP  requests  directly  into  protocol 
data  units  and  converts  them  to  ATM  cells.  This  is  necessary  because  IP  does 
not  recognize  conventional  MAC-layer  protocols,  such  as  those  generated  on 
an  Ethernet  LAN. 

•  Local  Area  Network  (LAN)  A  system  consisting  of  computer  and  communic¬ 
ations  hardware  and  software  connected  by  a  common  transmission  medium, 
usually  limited  to  a  scope  of  a  few  miles. 

•  LAN  Local  Area  Network. 

•  LDR  Low  Data  Rate. 

•  LNB  Low-Noise  Block. 

•  Link  Any  physical  connection  on  a  network  between  two  separate  devices,  such 
as  an  ATM  switch  and  its  associated  end  point  or  end  station. 

•  Megabits  Per  Second  (Mbps)  A  digital  transmission  speed  of  millions  of 
bits  per  second. 

•  MSE  Mobile  Subscriber  Equipment. 

•  Network-to- Network  Interface  (NNI)  In  an  ATM  network,  the  interface 
between  one  ATM  switch  and  another,  or  an  ATM  switch  and  a  public  ATM 
switching  system. 

•  NRaD  Naval  Command,  Control  and  Ocean  Surveillance  Center,  Research, 
Development,  Training,  and  Evaluation  Division 

•  OPNET  Optimized  Network  Engineering  Tools. 

•  OSI  Open  Systems  Interconnection. 
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•  Packet  Switching  A  switching  technique  in  which  no  dedicated  path  ex¬ 
ists  between  the  transmitting  device  and  the  receiving  device.  Information  is 
formatted  into  individual  packets,  each  with  its  own  address.  The  packets  are 
sent  across  the  network  and  reassembled  at  the  receiving  station. 

•  PCM  Pulse  Code  Modulation. 

•  PIR  Priority  Information  Requirements. 

•  PSH  Flag.  This  bit,  when  set,  activates  the  Push  Function.  The  Push  func¬ 
tion  pushes  this  packet  up  to  the  application  layer  even  if  the  buffer  is  not  yet 
full. 

•  Payload  Type  Identifier  (PTI)  The  3-bit  descriptor  in  an  ATM  cell  header 
that  indicates  whether  the  cell  is  a  user  cell  or  a  management  cell. 

•  Protocol  Data  Unit  (PDU)  A  unit  of  information  (e.g.,  packet  or  frame) 
exchanged  between  peer  layers  in  a  network. 

•  Permanent  Virtual  Circuit  (PVC)  A  generic  term  for  any  permanent,  pro¬ 
visioned  communications  medium.  NOTE:  PVC  does  not  stand  for  permanent 
virtual  channel.  No  such  term  has  been  defined  by  any  standards  organization. 
Neither  has  the  term  ’’permanent  virtual  path  (PVP).”  In  ATM,  there  are  two 
kinds  of  PVCs:  permanent  virtual  path  connections  (PVPCs)  and  permanent 
virtual  channel  connections  (PVCCs). 

•  Physical  Layer  The  first  layer  in  the  OSI  Model.  It  specifies  the  physical 
interface  (e.g.,  connectors,  voltage  levels,  cable  types)  between  a  user  device 
and  the  network. 

•  Point-to-point  A  term  used  by  network  designers  to  describe  network  links 
that  have  only  one  possible  destination  for  a  transmission. 

•  Quality  of  Service  (QoS)  The  ATM  Forum  has  outlined  five  categories  of 
performance  (Classes  1  through  5)  and  recommends  that  ATM’s  quality  of 
service  should  be  comparable  to  that  of  standard  digital  connections. 

•  RF  Radio  Frequency. 

•  RST  Flag.  This  bit  is  set  when  either  side  detects  problems  with  the  connec¬ 
tion  and  the  connection  must  be  reset. 

•  Segmentation  and  Reassembly  (SAR)  The  process  of  converting  protocol 
data  units  into  ATM  cells  (i.e.,  adjusting  the  length  and  format).  At  the  far 
end,  the  SAR  process  takes  the  payload  out  of  the  ATM  cells  and  converts  it 
back  into  protocol  data  units. 
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•  SDR  Surrogate  Data  Radio. 

•  Signaling  (ATM)  The  procedures  used  to  establish  connections  on  a  ATM 
network.  Signaling  standards  are  based  on  the  ITU’s  Q.93B  recommendation. 

•  SINCGARS  SIP  Single  Channel  Ground  and  Airborne  Radio  System  System 
Improvement  Program. 

•  SIV  System  Integration  Van. 

•  SPR  Secure  Packet  Radio. 

•  Switch  Device  used  to  route  cells  through  an  ATM  network. 

•  SSCS  Service  Specific  Convergence  Sublayer. 

•  Switched  Virtual  Circuit  (SVC)  A  generic  term  for  any  switched  commu¬ 
nications  medium.  NOTE:  SVC  does  not  stand  for  switched  virtual  channel. 
No  such  term  has  been  defined  by  any  standards  organization.  Neither  has  the 
term  “switched  virtual  path  (SVP).”  In  ATM,  there  are  two  kinds  of  SVCs: 
switched  virtual  path  connections  (SVPCs)  and  switched  virtual  channel  con¬ 
nections  (SVCCs). 

•  Sustainable  Cell  Rate  (SCR)  A  measure  of  the  maximum  throughput  that 
can  be  achieved  by  bursty  traffic  over  a  given  virtual  connection  without  the 
risk  of  cell  loss. 

•  Synchronous  A  term  used  to  describe  a  transmission  technique  that  requires  a 
common  clock  signal  (or  timing  reference)  between  two  communicating  devices 
to  coordinate  their  transmissions.  (Compare  with  ’’asynchronous.”) 

•  Synchronous  Optical  NETwork  (SONET)  A  set  of  standards  for  the  digital 
transmission  of  information  over  fiber  optics.  Based  on  increments  of  51  Mbps. 

•  Synchronous  Transfer  Mode  (STM)  In  ATM,  a  method  of  communications 
that  transmits  data  streams  synchronized  to  a  common  clock  signal  (reference 
clock).  In  SDH,  it  is  ’’Synchronous  Transport  Module”  and  is  the  basic  unit 
(STM-1=155  Mbps,  STM-4=622  Mbps,  STM-16=2.5Gbps)  of  the  Synchron¬ 
ous  Digital  Hierarchy. 

•  SYN  Flag.  A  bit  marking  this  packet  as  a  request  to  establish  a  connection. 

•  TCP  Transmission  Control  Protocol. 

•  TCP  HL.  TCP  HL  stands  for  TCP  Header  Length  and  specifies  the  total 
number  of  bytes  contained  in  the  header. 
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•  TEED  Tactical  End-to-End  Encryption  Device. 

•  TI  Tactical  Internet. 

•  TOC  Tactical  Operations  Center. 

•  TPN  Tactical  Packet  Network. 

•  Traffic  Shaping  A  mechanism  used  to  control  traffic  flow  so  that  a  specified 
Quality  of  Service  is  maintained. 

•  Usage  Parameter  Control  (UPC)  The  function  of  ATM  network  equipment 
that  controls  the  Cell  Loss  Priority  bit  to  control  congestion  on  the  network. 

•  UIM  Uplink  Information  Manager. 

•  UNI  User-Network  Interface. 

•  URG  Flag.  A  bit  that,  when  set,  tells  the  protocol  to  use  the  value  in  the 
Urgent  Pointer. 

•  UDP  User  Datagram  Protocol. 

•  User-to-Network  Interface  (UNI)  ATM  Forum  standard  that  defines  how 
private  CPE  interacts  with  private  ATM  switches.  A  connection  that  directly 
links  a  user’s  device  to  an  ATM  network  (usually,  through  an  ATM  switch). 
Also,  the  physical  and  electrical  demarcation  point  between  the  user  device 
and  the  ATM  switch. 

•  Variable  Bit  Rate  (VBR)  A  type  of  traffic  that,  when  sent  over  a  network, 
is  tolerant  of  delays  and  changes  in  the  amount  of  bandwidth  it  is  allocated, 
(e.g.,  data  applications) 

•  Virtual  Channel  Connection  (VCC)  A  logical  communications  medium 
identified  by  a  VCI  and  carried  within  a  VPC.  VCCs  may  be  permanent  virtual 
channel  connections  (PVCCs),  switched  virtual  channel  connections  (SVCCs), 
or  smart  permanent  virtual  channel  connections  (SPVCC).  Further,  VCC  is  an 
end-to-end  logical  communications  medium.  Another  acronym,  VCL  (virtual 
channel  link),  is  more  precise,  referring  to  the  single  segment  object  identified 
b\'  a  VCI  and  carried  within  a  VPC.  Similarly,  a  VPC  is  an  end-to-end  object 
and  a  \''irtual  Path  Link  (VPL)  is  identified  a  VPI  within  a  link. 

•  Virtual  Channel  Identifier  (VCI)  The  field  in  the  ATM  cell  header  that 
labels  (identifies)  a  particular  virtual  channel. 

•  Virtual  Circuit  (VC)  A  generic  term  for  any  logical  communications  medium. 
NOTE:  \'C  does  not  stand  for  virtual  channel.  Virtual  channels  are  referred 
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to  as  VCCs  (virtual  channel  connections).  There  are  three  classes  of  VCs: 
permanent,  switched,  and  smart  (or  soft)  permanent. 

•  Virtual  Path  Connection  (VPC)  A  logical  communications  medium  in  ATM 
identified  by  a  virtual  path  identifier  (VPI)  and  carried  within  a  link.  VPCs 
may  be  permanent  virtual  path  connections  (PVPCs),  switched  virtual  path 
connections  (SVPCs),  or  smart  permanent  virtual  path  connections  (SPVPCs). 
VPCs  are  uni-directional. 

•  VTC  Video  Teleconferencing. 

•  Virtual  Path  Identifier  (VPI)  The  field  in  the  ATM  cell  header  that  labels 
(identifies)  a  particular  virtual  path. 

•  WIU  Wireless  Integrated  services  digital  network  interface  Unit. 

•  WFA  Warfighter  Associate. 
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APPENDIX  B.  PROTO  C  CODE  FOR  STATIC 
CHANNELS  DEFINITION  AND  ALLOCATION. 


/*:)!*  +  %*!|5  +  ***4:+!(t******:********=f=**!t:*!t!*****>(:***=l==l=**=l'=t:*************!|t**+*/ 

/*  Read  the  channel  definition  file  and  define  static  channels  */ 
/*  for  the  ATM  switch.  */ 

void  load_static_channels_definition(temp_atm_state_ptr) 
AtmT_ATM_State*  temp_atm_state_ptr ; 

{ 


AtinT_VP_Desc* 

AtmT_VC_Desc* 

AtmT_Port_Desc* 

int 

int 

int 

int 

int 

int 

int 

int 

int 

int 

int 

char 

FILE* 


temp_vp_ptr; 
temp_vc_ptr; 
temp_pdesc_ptr ; 

MAX.CHANNELS  =  1024; 
MAXSIZE  =11; 
total.ports; 
port_count  =  0; 
total_paths; 
path_count  =  0; 
total_channels  =  0; 
vci_index  =  0; 
channel_count  =  0; 
value ; 

channel_array [1024] ; 
string [11] ; 
input _file; 


FIN(load_static_channels_def inition(temp_atm_state_ptr)) ; 


/* 

if 

} 


Open  the  channel  definition  file.  */ 

( (input _file  =  f open("/usr/work/benton/input_channels" ,  "r")) 

==  NULL) 


ams_atm_mgmt_error("Problem  opening  static  channel 

definition  file.”,  OPC.NIL,  OPC.NIL) ; 


/*  Read  the  first  line  to  get  the  number  of  requested  channels.  */ 
if  (fgets  (  string,  MAXSIZE,  input_file  )  !=  NULL) 

-c 

if  (LTRACE_STATIC_ACTIVE) 
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} 


printf("In  load_static_channels  function;  string  is  \y,s.", 
string) ; 

if  (get .digit (string,  &value)  ==  0PC_C0MPC0DE_FAILURE) 

■C 

ams_atm_mgmt_error  ("Invalid  number  of  static  channels.", 

OPC.NIL,  OPC.NIL); 

} 

total.channels  =  value; 
if  (LTRACE.STATIC.ACTIVE) 

{ 


} 


printf("In  load_static_channels  function  after  reading  ") ; 
printf ("channel  count ;total_channels  =  V/.d.", 
total.channels) ; 


if 

{ 

} 


(total.channels  >  MAX.CHANNELS) 

ams_atm_mgmt_error("Requested  virtual  channels  exceeds  allowed 

maximum.",  OPC.NIL,  OPC.NIL)  ; 


/*  Read  each  channel  definition  from  the  file  and  assign  the  */ 
/*  value  to  the  channel  array.  ♦/ 

while  ((fgets  (  string,  MAXSIZE,  input .file  )  !=  NULL)  && 

(channel .count  <  total.channels)) 

■c 

if  (LTRACE.STATIC.ACTIVE) 

{ 

printf ("In  load.static.channels  function,  reading  each  "); 
printf  ("  channel;  channel. count  =  '/.d.",  channel.count)  ; 
printf ("In  load.static.channels  function;  string  is  ys.", 
string) ; 

} 

if  (get.digit (string,  ftvalue)  ==  OPC.COMPCODE.FAILURE) 

ams.atm.mgmt. error  ("Invalid  number  for  static  channels.", 

OPC.NIL,  OPC  MIL); 

> 


if  (value  >  155000000) 

{ 
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> 


cims_atm_mgmt_error  ("Exceeded  channel  capacity  in 

static  definition  file.",  OPC.NIL,  0PC_NIL) ; 


chaiinel_array[channel_count]  =  value; 
channel_count  =  channel_count  +  1 ; 

if  (LTRACE.STATIC.ACTIVE) 

{ 

printf("In  load_static_channels  function,  value 
printf("=  %d.",  value); 

} 


} 

f close (input _file) ; 
if  (LTRACE.STATIC.ACTIVE) 

printf ("In  load.static.channels  function  after  closing  ") ; 
printf  ("file;  total.channels  =  */,d.\n",  total.channels) ; 

} 

total.ports  =  temp.atm.state.ptr->port.data.port_count ; 

if  (LTRACE.STATIC.ACTIVE) 

{ 

printf ("In  load.static.channels  function;  ") ; 
printf ("total.ports  =  \%d.",  total.ports); 

> 

port. count  =  0; 

while  (port. count  <  total.ports) 

{ 

temp.pdesc.ptr  = 

&temp.atin_state.ptr->port_data.port.axray  [port.count]  ; 
total .paths  =  temp.pdesc.ptr->vp.data. vp.count; 

if  (LTRACE.STATIC.ACTIVE) 

{ 

printf ("In  load.static.channels  function;  ") ; 
printf ("total .paths  =  %d.\n",  total.paths) ; 
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} 


path_count  =  0; 

while  (path_count  <  total_paths) 

{ 

temp_vp_ptr  = 

&temp_pdesc_ptr->vp_data. vp_array [path_count] ; 
if  (temp_vp_ptr->qos_desc. class  ==  3) 

{ 

ams_atm_vc_elements_add(temp_vp_ptr, 

total_channels) ; 

if  (LTRACE.STATIC.ACTIVE) 

{ 

printf("In  load_static_chcLnnels  function;  "); 
printf ("after  adding  channels  total_channels  = 
%d.\n",  total_channels) ; 

} 

channel.count  =0; 

while  (channel.count  <  total_channels) 

{ 

/♦  Assign  the  requested  bandwidth  to  the  channel  */ 
temp_vp_ptr->vc_array 

[channel_count] . alloc_bandwidth_in 

=  channel_array [channel.count] ; 
temp_vp_ptr->vc_array 

[channel_count] . alloc_bandwidth_out 

=  chcLnnel_array  [channel_count]  ; 
channel_count  =  channel_count  +  1; 

> 

} 

path_count  =  path_count  +  1; 


} 

port_count  =  port_count  +  1; 
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*/ 

*/ 


/+  User  did  not  provide  the  correct  number  of  channel 
/*  definitions. 

if  (channel_count  !=  total_channels) 


} 


ams_atm_mgmt_error  ("Did  not  define  correct  number  of 

channels",  0PC_NIL,  OPC.WIL) ; 


FOUT; 

} 


/  ♦*=|e!|c5tc  +  +  *=|c+*+3|:3it***+*+***%**  +  :t:***=(:*******:(:=|c=t:+****+*++*+******  +  ***:tc+++*/ 

/*  Verify  the  character  string  contains  only  numeric  digits  and  */ 
/♦  then  convert  the  character  string  to  a  number.  */ 

/  ♦********♦  +  ******♦*********♦***♦***=(!♦***********♦+**********♦♦******/ 

Compcode  get_digit  ( input _ string,  value) 
char*  input_string; 
int*  value; 

{ 

#define  YES  1 
#define  NO  0 

char  ch ; 
char  number [11] ; 
int  digit  =  YES; 
int  count  =  0; 

FIN (get_digit (input_string ,  value) ) ; 

/♦  Remove  the  newline  character  from  the  input  string  ♦/ 

while  ( (ch= input .string [count] )  !=  'Xn') 

number [count]  =  input.string [count] ; 
count  =  count  +  1; 

> 

number [count]  =  'XO'; 
count  =  0; 
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/*  Check  each  character  in  the  input  string  for  a  numeric  digit .  */ 

/*  If  any  chsiracter  fails  the  test,  set  the  flag  to  NO.  */ 

while  ( (ch=number [count] )  !=  '\0'  &&  digit  ==  YES) 

if  ( ! isdigit (ch)) 

-C 

digit  =  NO; 

} 

count  =  count  +1; 

} 

/*  If  all  the  characters  were  numeric  digits,  then  convert  the  */ 

/*  string  to  a  number  and  return  SUCCESS.  Otherwise,  return  */ 

/*  FAILURE.  */ 

if  (digit  ==  YES) 

{ 

♦value  =  atoi (input_string) ; 
if  (LTRACE_STATIC_ACTIVE) 

printfC'In  get.digit;  value  =  \%d.",  *value) ; 

FRET(OPC_COMPCODE_SUCCESS) ; 

} 

else 

FRET(OPC_COMPCODE_FAILURE) ; 

} 

/*  This  function  finds  a  valid  vitrual  path  and  channel  given  a  */ 
/*  specific  atm  switch  and  port  via  atm_state_ptr  and  port_value.  */ 
/*  respectfully.  */ 

/  +  ♦  + 

Compcode  ams_atm_avail_static_vp_vc_f ind  (atm_state_ptr, 

port_value,  vpi_value_ptr , 
vci_value_ptr , 
traf_con_ptr,  qos_class) 

AtmT_ATM_State*  atm_state_ptr ; 

int  port_value; 

int*  vpi_value_ptr; 
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int* 

AmsT.Traf .Contract* 
int 

AtmT.Port.Desc* 

AtmT_VP_Desc* 

AtmT_VC_Desc* 

int 

int 


vci_value_ptr; 
traf_con_ptr; 
qos.class ; 

pdesc.ptr; 
vp.ptr; 
vc.ptr ; 
vpi.index; 
vci.index; 


/*  This  procedure  finds  a  VPI  and  VCI  value  for  a  channel  in  */ 
/*  the  specified  direction  in  the  specified  port .  If  there  */ 
/*  is  no  VP  with  sufficient  available  bandwidth  and  correct  */ 
/*  Qos  class,  then  a  failure  status  is  returned;  otherwise,  */ 
/♦  success.  No  state  information  is  modified  concerning  the  */ 
/*  VP  and  VCs.  */ 

FIN  (ams_atm_avail_static_vp_vc_find  (<args>)); 

/*  Obtain  the  port  desc  pointer.  */ 

pdesc.ptr  =  &atm_state_ptr->port_data.port_array  [port .value] ; 

/*  Loop  through  the  VPs  on  the  port  and  find  one  with  */ 

/*  sufficient  bandwidth.  */ 

for  (vpi. index  =  0;  vpi. index  <  pdesc.ptr->vp.data.vp.count ; 
vpi.index++) 


/*  Do  not  use  the  signalling  VP.  */ 

if  (vpi.index  ==  AMSC.ATM.SIGVP.VPI) 
continue; 


/*  Obtain  the  vpi.index-th  in.VP  pointer.  */ 

vp.ptr  =  &pdesc.ptr->vp.data.vp.array  [vpi.index] ; 

/*  Determine  if  this  VP  has  the  correct  QoS  class.  ♦/ 

if  (vp.ptr->qos_desc .class  !=  qos.class) 

{ 

/*  This  VP  does  not  support  the  requested  QoS  class;  */ 
/*  continue  to  the  next  VP.  */ 

vp.ptr  =  OPC.NIL; 
continue; 

}  /*  End  if  vp.ptr->qos. desc .class  !=  qos.class  */ 


141 


/*  Determine  if  this  VP  can  support  the  traffic.  */ 


if  (ams_atm_vp_supports_treiff ic  (atm_state_ptr, 

port_value,  vpi_index, 
traf_con_ptr)  ==  OPC.TRUE) 

/*  This  VP  has  sufficient  bandwidth.  */ 

/*  Break  out  of  loop.  */ 

*vpi_value_ptr  =  vpi_index; 
break; 

y  /*  End  if  ams_atm_vp_supports_traff ic  */ 

/*  This  VP  has  insufficient  bandwidth.  Try  the  next  one.  */ 
/*  Set  the  pointer  to  NIL,  so  that  it  can  verified  if  the  */ 
/*  VP  search  failed.  */ 

vp_ptr  =  0PC_NIL; 

}  /*  End  for  loop  */ 

/*  If  the  VP  pointer  is  NIL,  then  the  search  failed.  */ 

/*  Handle  failure.  */ 

if  (vp.ptr  ==  OPC.NIL) 

{ 

FRET  (OPC_COMPCDDE_FAILURE) ; 

}  /*  End  if  vp_ptr  ==  OPC_NIL  */ 

/+  Found  an  available  VP  now  search  for  an  available  VC.  */ 

for  (vci_index  =  0;  vci.index  <  vp_ptr->vc_count ;  vci_index++) 

{ 

/*  Obtain  the  vci_index-th  in  VC  pointer.  */ 

vc_ptr  =  &vp_ptr->vc_array  [vci_index] ; 

/*  Determine  if  the  VC  is  free.  */ 

if  (vc_ptr->status  ==  AMSC_VC_FREE) 

/*  Determine  if  this  VC  can  support  the  traffic.  */ 

if  (ams_atm_vc_supports_traff ic  (atm_state_ptr , 


port_value,  vpi_index,  traf _con_ptr ,  vci_index) 

==  OPC.TRUE) 

{ 

/*  This  VP  has  sufficient  bandwidth.  ♦/ 

/*  Break  out  of  loop.  */ 

*vpi_value_ptr  =  vpi_index; 
break; 
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}  /*  End  if  ams_atm_vc_supports_traff ic  */ 

}  /*  End  if  vc_ptr->status  ==  AMSC_VC_FREE 

/*  The  VC  is  in  use.  Set  the  pointer  to  NIL.  */ 

vc_ptr  =  OPC_NIL; 

} 

/*  If  the  VC  pointer  is  NIL,  then  the  search  failed.  */ 

/*  Handle  failure.  */ 

if  (vc_ptr  ==  0PC_NIL) 

FRET  (0PC_C0MPC0DE_FAILURE) ; 

} 

else 

FRET  (0PC_C0MPC0DE_SUCCESS) ; 

> 

}  /*  End  function  ams_atm_avail_static_vp_vc_f ind  */ 


/  :t:******5(!***:t!+*!|!**  ♦♦♦♦si'***  / 

/*  This  function  allocates  a  specific  port,  virtual  path  and  ♦/ 

/*  virtual  channel  to  a  call.  */ 

/  +  +  :(!*♦**+**♦♦♦++♦♦*  +  +*♦+*♦**+*****♦+*♦*+*!(:*+ **+%%:(c+**!(c+*3|t  +  +*****:)c***  / 


AtmT_VC_Desc*  ams_atin_static_vp_vc_alloc  (atm_state_ptr, 

port_value,  vpi_value,  vci_value,  traf _con_ptr) 
AtmT_ATM_State*  atm_state_ptr; 

int  port_value; 

int  ■  vpi_value; 

int  vci_value; 

AmsT_Traf _Contract*  traf _con_ptr ; 

■C 


AtmT_Port_Desc* 

AtiiiT_VP_Desc* 

AtinT_VC_Desc* 

int 


pdesc_ptr; 

vp.ptr; 

vc_ptr; 

vc_add_count ; 


/*♦  This  procedure  allocates  the  VPI  and  VCI  to  the  call  and  */ 
/**  adjusts  the  available  bandwidth  values.  The  pointer  to  */ 
/**  the  specified  VC  ds  is  returned.  +/ 
FIN  (ams_atm_static_vp_vc_alloc  (<args>)); 
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/*  Verify  that  the  index  values  are  valid.  */ 

cLms_atm_static_port_vp_vc_verify  (atm_state_ptr, 

port.value,  vpi_value,  vci.value) ; 

/*  Obtain  pointers  to  the  port,  VP  and  VC  data  structures.  */ 

pdesc.ptr  =  &atm_state_ptr->port_data.port_array  [port .value] ; 
vp.ptr  =  &pdesc_ptr->vp_data. vp.array  [vpi.value] ; 
vc.ptr  =  &vp_ptr->vc_array  [vci.value] ; 

/*  Verify  that  the  VC  is  not  in  use.  */ 

if  (vc_ptr->status  ==  AMSC_VC_IN_USE) 

ams_atm_ error  ("VC  is  already  in  use.  Unable  to  allocate  VC 
for  call.",  OPC.WIL,  OPC.NIL) ; 


/*  Set  VP's  fields. 
vp_ptr->avail_bandwidth_in  -= 

traf_con_ptr->called_ctd. src_traf_desc.pcr  * 

AMSC.ATM_CELL_SIZE ; 

vp_ptr->avail_bandwidth_out  -= 

traf_con_ptr->calling_ctd. src.traf .desc.pcr  * 

AMSC_ATM_CELL_SIZE; 


vp_ptr->avail_vc_count — ; 


/*  Set  VC's  fields. 
vc_ptr->status  =  AMSC_VC_IM.USE; 


FRET  (vc.ptr) ; 

}/*  end  function  ams_atm_static_vp_vc_alloc 


*/ 


*/ 


*/ 


♦*****♦***♦♦**♦!(!******♦+**♦!(:♦  *♦  + ♦♦♦**♦♦*!(!+♦♦**♦!(:*  ♦♦♦*+♦♦*♦*♦  / 
/*  This  function  will  verify  the  port .value,  vpi.value  and  */ 

/*  vci.value  Eire  all  valid  for  the  atm  switch  defined  by  the  */ 

/*  atm.state.ptr .  */ 

void  ams.atm.static.port.vp.vc.verify  (atm.state.ptr, 

port .value,  vpi.value,  vci.value) 
AtmT.ATM.State*  atm.state.ptr; 
int  port.value ; 

int  vpi.value; 
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int 


vci_value; 


AtmT_Port_Desc*  pdesc.ptr; 

AtmT_VP_Desc*  vp_ptr; 

char*  attempt_msg  =  "Attempted  to  determine  use  of 

VP/VC  on  port."; 

/**  This  procedure  verifies  that  the  port,  VPI,  and  VCI  values  */ 
/**  are  valid.  If  not,  then  an  error  message  is  displayed  and  */ 
/**  the  simulation  is  terminated.  */ 

FIN  (ams_atm_static_port_vp_vc_verify  (args)); 


if  (port.value  <  0) 

ams_atm_error  (attempt _msg,  "Port  value  provided  is  negative, 
which  is  not  a  valid  value.",  0PC_NIL) ; 

} 

else  if  (vpi_value  <  0) 

ams_atm_error  (attempt_msg,  "VPI  value  provided  is 

negative,  which  is  not  a  valid  value.",  0PC_NIL) ; 

} 

else  if  (vci_value  <  0) 

ams_atm_ error  (attempt _msg,  "VCI  value  provided 

is  negative,  which  is  not  a  valid  value.", 
OPC.NIL) ; 

} 


if 

> 


(port_value  >=  atm_state_ptr->port_data.port_count) 

cLms_atm_error  (attempt _msg,  "Port  value  provided  is  greater 
than  any  actual  port . " ,  0PC_NIL) ; 


else 


pdesc_ptr  =  &atm_state_ptr->port_data.port_cirray 

[port.value] ; 


if  (vpi_value  >=  pdesc_ptr->vp_data.vp_count) 

ams_atm_error  (attempt_msg,  "VPI  value  provided  is 

greater  than  any  actual  VPI  within  the  port.". 
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OPC.NIL) ; 

} 

else 

vp_ptr  =  &pdesc_ptr->vp_data.vp_eirray  [vpi.value]  ; 

if  (vci.value  >=  vp_ptr->vc_count) 

/*  The  requested  VC  is  greater  than  any  in  the  VP.  */ 

ams_atm_error  (attempt_msg,  "VCI  value  provided  is  greater 
than  any  actual  VCI  within  the  VPI . " , 

OPC.NIL) ; 

} 

FOUT; 

}/*  end  function  ams_atm_static_port_vp_vc_verify  */ 


/*  This  function  verifies  the  virtual  cheinnel  can  support  the  */ 

/*  required  traffic  load.  */ 

/  ♦♦*****!t:+*********!|=*!t:  +  **!(=*+******:te***!*:st:*******+!t:**s|t*!(:*:(:*s|c*+**  +  !)c***%*/ 


Boolean  ams_atin_vc_supports_traff ic  (atm_state_ptr ,  port_value. 


AtinT_ATM_State* 
int 
int 
int 

AmsT_Traf .Contract*  traf.con.ptr; 


vpi.value,  traf.con.ptr,  vci.value) 
atm.state.ptr ; 
port .value; 
vpi.value; 
vci.value; 


AtmT.Port.Desc* 

AtmT.VP.Desc* 

AtmT.VC.Desc* 

Boolean 

double 

double 


pdesc.ptr; 

vp.ptr; 

vc.ptr; 

supports.traff ic; 
in.pcr ; 
out .per; 


/+  Determines  if  the  VC  can  accomodate  the  traffic  */ 
/♦  requirements.  If  so,  OPC.TRUE  is  returned;  else,  OPC.FALSE  */ 
FIN  (ams.atm.vc.supports.traff ic  (<args>)); 

/♦  Cache  the  incoming  and  outgoing  Peak  Cell  Rates  (PCRs)  as  */ 


146 


/*  defined  by  the  traffic  contract.  */ 

in_pcr  =  traf_con_ptr->called_ctd.src_traf_desc.pcr; 
out_pcr  =  traf_con_ptr->calling_ctd.src_traf_desc.pcr; 

/*  Obtain  the  port,  VP  and  VC  data  structure  pointers.  */ 

pdesc.ptr  =  &atiii_state_ptr->port_data.port_array  [port.value]  ; 
vp_ptr  =  &pdesc_ptr->vp_data.vp_array  [vpi.value] ; 
vc_ptr  =  &vp_ptr->vc_array [vci_value] ; 

/*  If  the  rate  is  less  than  that  available  in  the  VC,  then  the  */ 
/*  VC  is  available.  */ 

if  ( (vc_ptr->alloc_bandwidth_in  >  (in_pcr  * 

AMSC_ATM_CELL_SIZE) )  &&  (vc_ptr->alloc_bandwidth_out 
>  (out.pcr  *  AMSC_ATM_CELL_SIZE))) 

{ 

/+  The  VC  meets  the  requirements.  */ 

support s_traffic  =  0PC_TRUE; 

} 

else 

/*  The  VP/VC  does  not  meet  the  requirements.  */ 

supports_traff ic  =  OPC.FALSE; 

} 

FRET  (supports_traff ic) ; 

}  /*  end  function  ams_atm_vc_supports_traff ic  */ 
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APPENDIX  C.  BADD.CALLJIEQUESTOR. 
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Tue  Jun  17 10:34:49  1997  [  Page  1  of  18 


Process  Model  Report:  badd_cali_requestor 


External  Fite  Set  \ 

attribute 

value 

default  value 

external  file  set 

badd  functions 

tvoed  file 

ijpj:bcess  Model  Comments 

General  Process  Description: 


The  process  Initiates  call  requests  and  sends  them  to  the 
badd_calLscheduler  module. 

ICI  Interfaces: 

badd_caILreq_lfJci 

Packet  Formats: 

None. 

Statistic  Interfaces: 

None 

Process  Registry: 

Published  Attributes:  None 
Expected  Attributes:  None 

Restrictions: 

None 


Process  Model  Attributes 


Attribute  interarrival  time  properties 
Property:^ 


Value 


Default  Value: 

Data  Type: 

Attribute  Description: 
Auto,  assign  value: 
Units: 

Low  Range: 
Comments: 


0.001 

double 

Private 

FALSE 

seconds 

0.0  exclusive 

Specifies  the  Interarrival 

time  between  packets. 


Attribute  packet  size  properties 


Property _ _ _ Value 

Default  Value:  1000 

Data  Type:  integer 

Attribute  Description:  Private 

Auto,  assign  value:  FALSE 
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Units: 

Comments: 

bits 

Specifies  the  size  of  the 
packets  generated  (in  bits). 

Attribute  call  wait  time  properties 

Prooertv 

Value 

Default  Value: 

10 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Low  Range: 

0.0  exclusive 

Comments: 

Specifies  the  time  between 
calls. 

Attribute  call  duration  properties 

Property 

Value 

Default  Value: 

1,000 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Low  Range: 

0.0  exclusive 

Comments: 

Specifies  the  length  of  a 
call. 

Attribute  dest  addr  properties 

Propertv 

Value 

Default  Value: 

NONE 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  destination  of 
the  call. 

Symbol  Map: 

Symbol 

Value 

NONE 

-1 

Allow  other  values: 

YES 

Attribute  AAL  type  properties , 

Propertv 

Value 

Default  Value: 

5 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  AAL  type  to  be 
used. 

Symbol  Map: 

Symbol 

1 

2 

Value 

1 

2 

34 

34 
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5 

5 

Allow  other  values: 

NO 

Attribute  QoS  class  properties 
Property 

Vafue 

Default  Value: 

D 

Data  Type: 

string 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  QoS  class. 

Symbol  Map: 

Symbol 

Value 

A 

A 

B 

B 

c 

c 

D 

D 

Allow  other  values: 

NO 

Process  Model  Interface  Attributes  1 

Attribute  begsim  intrpt  properties 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  a  'begin  simulation 
interrupt’  is  generated  for  a  processor  module’s  root 

process  at  the  start  of  the  simulation. 

Symbol  Map: 

NONE 

YES 

Attribute  endsim  intrpt  properties 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  an  ’end  simulation 
interrupt’  is  generated  for  a  processor  module’s  root 

process  at  the  end  of  the  simulation. 

Symbol  Map: 

NONE 

YES 

Attribute  failure  intrpts  properties 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 
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Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

This  attribute  specifies  whether  failure  interrupts 

YES 

are  generated  for  a  processor  module's  root  process 
upon  failure  of  nodes  or  links  in  the  network  model. 

Symbol  Map; 

NONE 

YES 

Attribute  Intrpt  interval  properties 
Prooertv 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle  double 

N/A 

Attribute  Description: 

Private 

N/A 

Units: 

sec. 

YES 

Comments: 

YES 

This  attribute  specifies  how  often  regular  Interrupts 
are  scheduled  for  the  root  process  of  a  processor  module. 

Symbol  Map: 

NONE 

YES 

Attribute  priority  properties 

Prooertv 

Value 

fr7herit 

Assign  Status; 

hidden 

Initial  Value: 

0 

N/A 

Default  Value: 

0 

YES 

Data  Type: 

Integer 

N/A 

Attribute  Description: 

Private 

N/A 

Low  Range: 

-32767  inclusive 

YES 

High  Range: 

32767  inclusive 

YES 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 
of  events  that  are  scheduled  to  occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Attribute  recovery  intipts  properties 
Prooertv 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  recovery  interrupts 
are  scheduled  for  the  processor  module’s  root  process 
upon  recovery  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 
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Attribute  super  priority  properties 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 

of  events  that  are  scheduled  to  occur  at  the  same 
simulation  time. 

Symbol  Map: 

NONE 

YES 

Process  Model  Simulation  Attributes 

Attribute  class_A_CDV_tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 

Service  (QoS)  class  A  cells 
may  experience. 

j  Attribute  class_B_CDV_tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  B  cells 

may  experience. 

1  Attribute  class_C_CDyj:olerance  properties  .  . 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  C  cells 
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Header  Bfock 


#include  " /usr/local/mil 3_dir/3 . 0 .A_DL5/models/std/atm/ams_interfaces .h " 
#include  *  /usr/local/inil3_dir/3 . 0  .A_DL5/inodels/std/atin/ains__aal_interfaces  .h" 
/*  Code  added  for  badd  */ 

#include  "  /usr/work/benton/op_code/badd_interface  .h" 

5  /*  end  code  added  for  badd  */ 


/*  These  are  transition  conditions.  */ 


#define  SIGNAL 


#defineEST_CON 


#defineREL_IND 


15  #defineRH.  CON 


#define  CALL  START 


20  #define  CALL_END 


((op  jDtrpt Jype  ()  =  OPC  JNTRPT_REMOTE)  &&  \ 

(op  Jntrpt_code  ()  =  AMSC_INTERFACE_SIGNAL)) 

(SIGNAL  &&  (primitive  =  AMSC„AAL_ESTAB_Con)) 

(SIGNAL  &&  (primitive  =  AMSC_AAL^RELEASE^Ind)) 

(SIGNAL  &&  (primitive  ==  AMSC^AAL_RELEASE_Con)) 

((opjntrpt Jype  ()  =  OPCJNTRPT_SELF)  &&  \ 

(op  Jntrptjode  ()  =  AMSC_TGEN_CALL^START)) 

((op  Jntrpt  Jype  ()  =  OPCJNTRPT.SELF)  &&  \ 

.  (op  jntrpt^code  ()  =  AMSC„TGEN^CALL_END)) 


#defme  NEIGHBOR.NOTIFY  ((op  Jntrpt  Jype  ()  =  OPCJNTRPT__REMOTE)  &&  \ 

(opJntrptjode  ()  =  AMSC.NEIGHBOR^NOTIFY)) 

25 

#defme  NOTIFY_COMPLETE  (ams_neighbor_notifyJs_compIete  (nbr_daia_ptr)  =  OPC_TRUE) 
Code  added  for  badd  *1 

#define  WAIT_CALL_DURATION  ((opjntrpt Jype  ()  =  OPC^INTRPT_SELF)  &&  \ 

30  (opJntrpt_code  ()  =  AMSC_TGEN_WAIT_CALL_DURATION)) 

End  code  added  for  badd  */ 

/*  These  are  the  ams_traf__gen  self  interrupt  codes.  *1 
#denne  AMSC_TGEN_CALL_START  0 
35  #define  AMSC.TGEN^CALL^END  1 
#derine  AMSC_TGEN_DATA_GEN  2 
/*  Code  added  for  badd  *1 

#define  AMSC_TGEN_WAIT^CALL_DURATION  3 
/*  End  code  added  for  badd  */ 
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40 


/*  The  amsjraf^gen  process  will  output  trace  information  if  this  conditional  is  true.  *f 
#define  LTRACE.ACTIVE  (debug^mode  &&  .  \ 

(op_prg_odb  Jtrace^active  ( "  ams " )  II  \ 

op_prg_odb_Itrace_active  ( "  ams_t  ra f " )  II  \ 

op_P**g_odb__Itrace_active  ( "  aiTis_t  raf_gen  “))) 

#defiDe  LTRACE__CONNECT_ACTIVE  (op_prg_odbJtrace_active  ( “connect ")) 


50 


/*  Code  added  for  badd  */ 

#define  LTRACE^CALL^REQUESTOR.ACXrVE 


(op_prg_odb  Jtrace_acti ve  ("call _req  ues  t  o  r " )) 


55 


/*  Procedure  declarations.  */ 
void  badd_calI_req_nbr_iiitrpt_proc  (); 
void  badd_calLreq_spurious_signaJ_handIe  (); 
void  badd_calLreq_error  (); 


60 


65 


State  Variable  Block 


10 


15 


20 


25 


int 

int 

Distribution* 

Distribution* 

Distribution* 

double 

Objid 

Ici* 

Evhandle 

Evhandle 

int 

char 

int 

Objid 

int 

int 


\debug_mode; 

Npacket_size; 

\int_arrivaJ„distptr; 

\call_wait_distptr; 

.  \call_duration_distptr, 
\avg__rate; 
\aal_module_id; 
Naal_handle_iciptr; 
Nnext_packet_aiTivaJ; 
\call_end_intrpt; 
\dest_addr; 

Npid_string  [128]; 

\to_aal_stream_index; 

Nmyjd; 

\AAL_type; 
\qos_class; 


AmsT_Traf_Contract*  ^lraf_con_ptr; 
AmsT_Neighbor_Data*  \nbr_data_ptr; 

/*  Code  added  for  badd  */ 
double 
double 
double 
Objid 
int 


Badd_Sch„Mod_Data 

Badd_Sch_CalJ_Desc 


\int_arr_time; 

\call_wait_time; 

NcalLduration; 

\sch_module_id; 

'^o^sch_stream_index; 

\ScheduIer_ModuIe; 
\Scheduler_CalI; 
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jemporarv  Variable  Block 


int  primitive; 

Packet*  pkptr; 

Ici*  if_iciptr; 

AmsT_Traf_Contract*  tmp_traf_con_ptr; 

5  double  peak_ceILrate; 

char  qos_class_string  [128]; 

double  cdv  tolerance; 


/*  Code  added  for  badd  */ 


10  int 
int 

double 

double 

double 

15  extern  int 


cd_packet_si2e; 

clark_dest_addr; 

badd_packet_size; 

event_time; 

end_sim_time; 

total_caIls_requested; 


Prohandle  caII_gen_prohandle; 
/*  End  code  added  for  badd  */ 


Function  Block 


void 

badd_calI_req_nbr_intrpt_proc  (ndata_ptr,  ndesc_ptr,  state_ptr) 
AmsT_Neighbor_Data*  ndata^ptr; 

AmsT_Neighbor_Desc*  ndesc_ptr; 

5  void*  state_ptr; 

{ 

AmsT_Neighbor_Verify_Desc  vdesc; 

int  to_sw_stream_index; 

10  /**  This  procedure  handles  a  neighbor  notification  event  in  an  AMS 

/**  traf  gen  specific  manner.  It  determines  the  neighbor' s  object 
/**  ID  and  type,  and  verifies  that  there  are  a  correct  number  of 
/**  interconnections. 

FIN  (badd_calLreq_nbr_intrpt_proc  (ndata_ptr,  ndesc_ptr,  state_ptr)); 
15 

/♦  Switch  based  on  the  AMS  type. 
switch  (ndesc_ptr">module_amstype) 

{ 

case  AMSC_MTYPE_AAL_CLIENT: 


/*  Build  the  verify  desc  data  structure. 


vdesc.mod_id 

vdesc.nbr_id 

vdesc.nbr_id_ptr 

vdesc.mod_name 

vdesc.nbr_name 

vdesc.nbr_type 


=  my_id; 

=  ndesc_ptr->module_objid; 

=  &sch_module_id; 

= "BADD  Call  Requestor"; 

= "call_sch"; 

=  AMSC_MTYPE_AAL_CLIENT; 
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vdesc.fi-oni_nbr_stnn_cnt  =  1; 

vdesc.from_nbr_strm_index_ptr  =  OPC_NIL; 

30 

vdesc.to_nbr_strm_cnt  =  1; 

vdesc.to_nbr_stnn_mdex_ptr  =  &to_sch_stream_index; 

/*  Verify  that  the  neighbor  has  the  correct 

*/ 

1*  characteristics. 

*/ 

35 

ams_neighbor_verify  (&vdesc); 

break; 

} 

40 

default: 

{ 

/*  This  is  an  unexpected  neighbor  notification. 

♦/ 

i*  Issue  error  message. 

*/ 

45 

op_sim_end(“ Process  received  a  neighbor  notification 

from  a  module". 

"of  an  unexpected  type.  Simulation  terminated." 

,  OPC^NIL,  OPC.NIL); 

break; 

) 

50 

) 

FOUT; 

) 

void 

55 

badd_call_req  spurious  signal  handle  () 

{ 

Ici*  if_iciptr; 

Ici*  release_if_iciptr; 

int  primitive; 

60 

Ici*  ll_handle_iciptr; 

Packet*  pkptr, 

/*  This  procedure  handles  spurious  interrupts. 

♦/ 

65 

1*  Only  three  types  of  spurious  interrupts  can  be  accepted.  All 

*/ 

/*  others  must  result  in  an  op  sim  end  ().  These  three 

*/ 

/*  interrupts  are: 

*/ 

/*  I.  AnAALESTABInd. 

*/ 

/*  2.  An  AAL  RELEASE  Con. 

*/ 

/*  3.  A  packet  arrival.  . 

*/ 

70 

FIN  (badd_calLreq_spurious_signal_handle  ()); 

if  (SIGNAL) 

{ 

/*  This  is  a  signal  from  the  AAL. 

*/ 

75 

/*  Obtain  the  ICI  pointer. 
iLiciptr  =  opjntrptjci  (); 

*/ 

/*  Obtain  the  primitive  from  the  ICI. 

*/ 

80 

(if-iciptr,  "primi  t  ive ",  &primitive); 

/*  Obtain  the  'lower  layer  handle’  from  the  ICI. 

(if-iciptr,  "  1  ower  1  ay er  handle",  &II_handle_iciptr); 

*/ 

85 

/*  Switch  on  the  ’primitive’ .  */ 

switch  (primitive) 
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case  AMSC_AAL_ESTAB_Ind: 

{ 

f*  This  is  an  '  establish  indication’  from  the  AAL.  *1 

if(LTRACE_ACnVE) 

{ 

op_prg_odb_priDt_major(pid_string,  "Received  spurious  AAL  ESTABLISH  Request  signal. 
"Call  not  accepted.",  "Sending  AAL  RELEASE  Request  signal.  ",OPC  NIL); 

} 

/*  Set  the  ’upper  layer  handle’  in  the  interface  *l 

/*  ICI  for  the  ’establish  indication’  signal,  since  *! 

/*  the  lower  layer  expects  it  to  be  filled  in.  The  *! 

I*  ICI  is  not  destroyed,  since  this  is  a  forced  *1 

/*  interrupt  and  the  lower  layer  process  expects  *1 

/*  to  obtain  the  handle  from  the  ICI  when  the  *! 

/*  control  returns.  *} 

op_ici__attr_set(if_iciptr,  "upper  layer  handle",  OPC_NIL); 

/*  Simply  send  an  AALJRELEASEJieq  to  request  that  */ 

/*  the  connection  be  released.  *f 

release_if_iciptr  =  op_ici_create  (AMSC_INTERPACE_ICI); 
op Jci_attr_set  (release_if  Jciptr,  "primitive",  AMSC_AAL_RELE ASE_Req); 
op (release_if_iciptr,  "  1  ower  layer  handle",  ll_haiidle_iciptr); 
op_icMnstall  (release_if_iciptr); 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  module.  */ 
opJntrpt_schedule_remote  (op^simjime  (),  AMSC_INTERFACE_SIGNAL,  aal_moduleJd); 


case  AMSC_AAL_RELEASE_Con: 

{ 

/*  This  is  a  ’release  confirm’  from  the  AAL.  *} 

if(LTRACE_ACTIVE) 

{ 

op_prg_odb_print_major(pid„strmg,  "Received  spurious  AAL  RELEASE  Confirm  signal.", 
“This  is  in  response  to  AAL  RELEASE  Request  terminating  spurious  connection. 

) 

/*  This  is  a  response  to  our  earlier  ’release  */ 

/*  request’  which  was  a  response  to  the  *} 

I*  spurious  ’estab  indication’.  *f 

/*  Do  nothing  other  than  destroy  the  ICI.  *f 

op_ici_destroy  (tfjciptr); 


default: 

( 

/*  This  is  some  other  completely  unexpected 
I*  signal.  Issue  error  message  and  terminate 
I*  simulation. 

op_sim  end  ("Received  unexpected  signal.","" 

} 
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) 

) 

else  if  (op  intrpt  type  ()  =  OPC  INTRPT  STRM) 

{ 

/*  This  is  a  spurious  packet  arrival.  The  cans  traf  gen  */ 

/*  just  destroys  this  packet.  *f 

if(LTRACE^ACnVE) 

{ 

(pi<^-String,  "Received  spurious  DATA  packet.", 

"Destroying  the  packet.",  OPC  NIL); 

} 

150 

155 

160 

/♦  Get  the  packet  fromt  the  stream  and  destroy  it.  */ 

pkptr  =  op_pkjget  (op_intrpt_strm  ()); 

.  op  pk  destroy  (pkptr); 

} 

else 

{ 

/*  This  is  some  other  completely  unexpected  *! 

1*  interrupt.  Issue  error  message  and  terminate  */ 

/*  simulation.  */ 

op  sim  end  ("Received  unexpected  interrupt.",  ""); 

} 

165 

170 

FOUT; 

} 

175 

void 

badd_caIl_req_eiTor  (msgO,  msgl,  msg2) 
char*  msgO; 

char*  msgl; 

char*  msg2; 

{ 

/**  Print  an  error  message  and  exit  the  simulation.  **/ 

FIN  (badd_caILreg_erTor  (msgO,  msgl,  msg2)); 

180 

op_sim_end ("Error  in  badd_can_requestor  process:", 
msgO,  msgl,  msg2); 

185 

FOUT; 

} 

Oia 

onc^lc  Block 

5 

/*  Display  connection  information,  if  requested.  *1 
if  (LTRACE  CONNECT  ACTIVE) 

{ 

/*  Print  information.  */ 

ams_neighbor_data_print  (nbr_data_ptr,  ams  neighbor  desc  print  noop); 

} 
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forced  state  INiT  I 

attribute 

value 

ivpe 

default  value 

name 

INIT 

string 

St 

enter  execs 

(See  below.) 

textiist 

exit  execs 

(empty) 

textiist 

(empty) 

status 

forced 

toggle 

unforced 

ierite 

rexecs  INIT 

/*  Determine  the  initial  values  of  the  state  variables  and  set  up 

*l 

/*  the  initial  state  of  this  instantiation  of  the  amsjraf  gen 

*1 

/*  process. 

*1 

5 

1*  Obtain  the  object  ID  of  this  process'  parent  module. 
my Jd  =  op_id_se1f  (); 

*! 

/*  Obtain  the  attribute  values  for  the  packet  interarrival 

*f 

/*  time,  size,  wait  time  between  calls,  call  duration,  and 

*/ 

10 

}*  destination  address.  These  values  are  process  attributes. 
op_ima_obj_attrjget  (my_id,  “interarrival  t  ime " ,  &int_arr_time); 
op_ima_obj_attr__get  (my Jd,  “  pacXe t  size",  &packet_size); 
op_iina_obj_attrjget  (my_id,  “call  wait  time",  &call_wait_time); 
op  Jma_obj_attr jget  (my  Jd,  “call  duration",  &calLduration); 

*l 

15 

op_ima_obj_attrjget  (myjd,  "dest  addr",  &dest_addr); 
op Jma_obj__attrjget  (myjd,  “QoS  class",  qos„class_string); 

op Jma_obj_attrjget  (myjd,  “AAL  type", &AALjype ); 

1*  Convert  the  Quality  of  Service  class  character  into  *1 

20 

/*  the  index  value  and  check  its  validity.  *f 

ams_qos_class_char_to_index_convert(qos_class_string  [0],  &qos_class); 
if  (qos.class  =  AMSC^QOS^CLASS^UNDEF) 

{ 

/*  The  QoS  Class  value  is  invalid.  Issue  error  message  *! 

25 

/*  and  terminate  the  simulation.  */ 

op_sim_end (“Specified  Quality  of  Service  Class  attribute 

value  is  invalid.", 

"Value  must  be  'A",  *C' ,  or  '  D' 

} 

30 

/*  Load  in  the  call  wait  distribution  *1 

calLwait_distptr  =  op_distJoad("  constant  “ ,  calLwaitJime,  0.0); 
call_duration_distp1r  =  op_dist Joad  ("constant ",  caIl_duration,  0.0); 

/*  determine  whether  or  not  the  simulation  is  in  debug  mode. 

*1 

35 

debug_mode  =  op_sim_debug  (); 

40 

/*  Initialize  the  AAL  module  object  ID  to  NULL  value. 
aal_module_id  =  OPC_OBJID_NULL; 
sch_module_id  =  OPC_OBJID_NULL; 

*/ 

/*  Generate  PID  display  string. 

sprintf  (pid_string,  "badd_call_requestor  PID  (%d)  “,  op_proJd  (opjpro_self  ())); 

/*  Obtain  and  send  out  neighbor  information. 

*1 

45 

nbr_data_ptr  =  ams_neighbor_data_build  (); 

ams_neighbor_notify  (nbr_data_ptr,  BADD_MTYPE_SCHEDULER_CLIENT); 
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50 


55 


f*  Code  added  by  BADD  *l 
if  (LTRA(::E_CALL_REQUESTOR_.ACriVE) 

{ 

printf("In  badd_call_requestor . init :  printing  badd_cal l_requestor  neighbor  info.\n"); 
/*  ams_neighbor_data _print  (nbrjiata _ptr,  ams_neighbor_desc _print_noop); 

I*  baddj:all_req_error  ("In  badd_call  requestor. init:  ending  simulation  test.W);  *f 

}  /*  End  if(LTRACEj:ALL_REQUEST5R_ACTIVE)  *1 


60 


if  (LTRACE.C  ALL_REQUESTOR_ACTIVE) 

{ 

printf("ln  badd_call_requestor. init  state:  Leaving  init  state.  \n"); 

} 


/*  End  code  added  for  BADD  *l 
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textiist 
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10 


/*  Amsjrafjgen  expects  either  a  neighbor  notification  interrupt,  *1 

!*  or  a  spurious  signal.  */ 

if  (NEIGHBOR_NOTIFY) 

{ 

/*  This  is  a  *  neighbor  notify'  signal.  */ 

if(LTRACE^ACnVE) 

{ 

op_prg_odb_print_iiiajor (pid_string,  "Received  neighbor  notification. ",  OPC_NIL); 
} 

/*  Handle  the  neighbor  notification.  */ 

ams_neighbor_interrupt_handle  (nbr_data_ptr,  badd_calLreq_nbr_intrpt_proc,  OPC_NIL); 

} 

else 


15 


{ 

This  is  a  spurious  interrupt.  Handle  appropriately. 


*f 
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badd_calLreq_spurious_signal_handle  (); 
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textiist 
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toggle 
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/*  Code  added  for  BADD  */ 

event_time  =  op_sim_time()  +  op__dist_outcome  (caJl_wait_distptr); 

5  if  (LTE^CE.CALL^REQUESTOR^ACriVE) 

{ 

printf(*'In  clark_badd_call_requestor .schedule;  schedule  start  for  %f.\n“ 
event_time); 

) 

10  /*  End  code  added  for  BADD  */ 

/*  Start  call  by  scheduling  self  intrpt.  */ 

op_iiitrpt_schedule_self  (event_time,  AMSC_TGEN_CALL_START); 
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/*  Ams_trafjgen  expects  two  interrupts: 

I*  LA  self  interrupt  that  signals  a  new  call. 

1*2.  A  spurious  interrupt. 

5  /*  If  this  is  not  a  call  start  handle  the  spurious  interrupt; 

!*  otherwise,  the  transition  conditions  will  cause  the  process  to 
/*  go  to  the  ’start’  state. 
if  (!  CALL_START) 

{ 

10  /*  This  is  a  spurious  interrupt.  *1 

badd_calLreq_spurious_signal_handIe  (); 

} 
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ar^ed  state  start 


enter  execs  Start _ _ _ 

/*  Start  a  call  by  issuing  a  call  open  request  to  the  ATM  *f 

/*  adaptation  layer.  */ 

if(LTRACE_ACnVE) 

{ 

5  op_prg_odb_priiit_major  (pid_string,  -  Ini  t iat  ing  ca  1 1  Request .  - , 

"Sending  Request  signal  to  Call  Scheduler OPC_NIL); 


10  !*  Code  added  by  Clark  *f 

if  (LTT^CE_CAIX_REQXJESTOR_ACTIVE) 

{ 

printf("In  badd_call_requestor/  start;  reached  start  stateAn"); 
}  /*  Jf(LTRACE_CALL_REQUESTOR_ACTfVE)  */ 

15 

I*  Create  and  set  the  fields  in  the  interface  ICI.  *1 

ifjciptr  =  opJci_create  ("badd_cal  l_req_if_ici  “); 

I*  Code  commented  out  for  badd  testing  *f 
20  opJci_install  (ifjciptr); 

/*  End  commented  out  code  *f 


badd_packet_size  =  packet_size; 

25  /*  Compute  the  peak  cell  rate  in  cells! second,  which  is  set  to  I  *} 

/*  times  the  average  cell  rate  in  this  example.  */ 

peak_ceILrate  =  (1.0  /  int_arr_tiine)  *  (badd_packet_size  /  AMSC_ATM_CELL_DATA_SIZE); 


op_ici_attr_set  (ifjciptr, 
op  Jci_attr_set  (ifjciptr, 
op  Jci_attr_set  (ifjciptr, 
op  Jci_attr_set  (ifjciptr, 
op  Jci_attr_set  (ifjciptr, 
op Jci_attr_set  (ifjciptr, 
op  Jci_attr_set  (ifjciptr, 
op  Jci_attr_set  (ifjciptr. 


“interarrival  time", int^aiTjime); 
"packet  size",  packet_size); 

"call  wait  t ime",  calLwaitJime); 
"call  duration",  call_duxation); 
"dest  addr",  dest_addr); 

"QoS  class",  qos_class); 

"AAL  type",  AAL^type); 

"peak  cell  rate", peak_cell_rate); 


/*  Code  added  by  Clark  *1 
if  (LTRACE_CALL^REQUESTOR_ACTIVE) 

40  { 

printf("In  badd_call_requestor,  start;  starting  call  to  dest  %dAn" 
dest_addr); 

}  f*  ifiLTRACEJCAUJlEQUESTORJiCTfVE)  *1 
45  /*  End  of  code  added  by  Clark  */ 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  */ 
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/*  module.  */ 

50 

/*  Code  commented  out  for  badd  testing  *! 

op Jntrpt_scheduIe_remote  (op_sim_tiiiie  (),  BADD_REQUEST_SIGNAL,  sch_inodule Jd); 

/*  End  commented  out  code 

55 

!*  Generate  a  self  intrpt  to  wake  up  this  process  for  generating  */ 

/*  another  call  request.  ♦/ 

if(L'mACE„CALL^REQUESTOR  ACTIVE) 

{ 

event_tiine  =  op_slm_time()  +  op_dist_outcome  (call_duration_dis^tr); 
priiltf("In  clark_badd_cal l_requGstor. start ;  schedule  call  completion  for 
event  time); 

} 

60 

65 

op  Jntrptscheduleself  (opsimtime  ()  + 

op__dist_outcoiDe  (calLduration_distptr),  AMSC_TGEN_WAIT_CALL_DURATION); 

transidon  start  ->  wait 

call  duration 

.  ya/ue 

default  value 

name 

tr_105 

String 

tr 

condition 

string 

executive 

String 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

!  unforced  state  wait  call  duration  I 

attribute 

value 

default  value 

name 

wait  call  duration 

string 

St 

enter  execs 

(empty) 

textiist 

(empty) 

exit  execs 

(See  below.) 

textiist 

status 

unforced 

toggle 

unforced 

\  exit  execs  wait  call  duration  I 

/♦  wait_call_duration  expects  two  interrupts: 

*1 

}*  LA  self  interrupt  that  signals  expired  call  duration  time. 

*/ 

1*2.  A  spurious  interrupt. 

*! 

5 

/*  If  this  is  not  a  call  start  handle  the  spurious  interrupt; 

*/ 

f*  otherwise,  the  transition  conditions  will  cause  the  process  to 

*1 

/*  go  to  the  ‘start’  state. 

*1 

if  (!  WAIT_CALL_DURATION) 
r 

10 

1 

/*  This  is  a  spurious  interrupt.  */ 

badd  call  req_spurious  signal  handle  (); 

) 
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transMon  wait  call  duration ->  wait  call  duration 


attribute 

value 

.  :v  default  value 

name 

tr_96 

String 

tr 

condition 

default 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

transidon  wait 

call  duration  ->  schedule 

attribute 

value 

default  value 

name 

tr  100 

String 

tr 

condition 

WAIT_CALL_DURATION 

string 

executive 

String 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 
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ExtemalFUe  Set  \ 

attribute 

value 

default  value  . 

external  file  set 

badd  functions 

tvoed  file 

Process  Model  Comments 

General  Process  Description: 


The  ams__traf_gen  process  initiates  call  start  and  end,  generates  the 
actual  packets,  and  sends  them  to  the  AAL  module.  It  provides  an  example 
of  an  AAL  client  process. 

ICl  Interfaces: 


ams_ifjci 
Packet  Formats: 


None. 

Statistic  Interfaces: 


None 

Process  Registry: 


Published  Attributes:  None 
Expected  Attributes:  None 

Restrictions: 


None 


Process  Modef  Interface  Attributes  1 

Attribute  begsim  intrpt  properties. 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  a  ’begin  simulation 

interrupt’  is  generated  for  a  processor 
process  at  the  start  of  the  simulation. 

module’s  root 

Symbol  Map: 

NONE 

YES 

Attribute  endsim  intrpt  properties 
Property 

Value 

ffiiie lit  ■: 

Assign  Status: 

hidden 
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Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  an  'end  simulation 
interrupt’  is  generated  for  a  processor  module’s  root 

process  at  the  end  of  the  simulation. 

Symbol  Map: 

NONE 

YES 

Attribute  ^ilure  intipfs  properties 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

This  attribute  specifies  whether  failure  interrupts 

YES 

are  generated  for  a  processor  module’s  root  process 
upon  failure  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  intrpt  interval  properties 
Property 

Value 

Inherit  .  . 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle  double 

N/A 

Attribute  Description: 

Private 

N/A 

Units: 

sec. 

YES 

Comments: 

YES 

This  attribute  specifies  how  often  regular  interrupts 
are  scheduled  for  the  root  process  of  a  processor  module. 

Symbol  Map: 

NONE 

YES 

Attribute  priority  properties 

Propertv 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

0 

N/A 

Default  Value: 

0 

YES 

Data  Type: 

integer 

N/A 

Attribute  Description: 

Private 

N/A 

Low  Range: 

-32767  inclusive 

YES 

High  Range: 

32767  inclusive 

YES 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 
of  events  that  are  scheduled  to  occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 
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Attribute  recovery  intipts  properties 
Propertv 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  recovery  interrupts 
are  scheduled  for  the  processor  module’s  root  process 

upon  recovery  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  super  priority  properties 
Propertv 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 
of  events  that  are  scheduled  tc  occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Process  Model  Simulation  Attributes 

Attribute  class_A_CDV  tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 

Service  (QoS)  class  A  cells 
may  experience. 

1  Attribute  class_B_CDV_tolerance  properties 

Propertv 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
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consecutive  Quality  of 
Service  (QoS)  class  B  cells 
may  experience. 


Attribute  class_C_CDV_tolerance  properties 

Propertv 

Value 

Default  Value; 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 

Service  (QoS)  class  C  cells 
may  experience. 

i  Attribute  c[ass_D_CDy_tolerance  properties  = 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description; 

Private 

Auto,  assign  value; 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  D  cells 
may  experience. 

Header  Block 


10 


15 


20 


#iDClude  " /usr/local/mil 3_dir/3 .0 . A_DL5/models/std/atm/ams_interfaces .h“ 
#iDclude  " /usr/local/mil 3_dir/3 -0 .A_DL5/modGls/std/atm/ams_aal_interfaces .h" 
/*  Code  added  by  Clark  */ 

#iDclude  " /usr/work/benton/op_code/badd_interf ace .h" 

/*  end  code  added  by  Clark  *f 

/*  These  are  transition  conditions.  *1 

#define  SIGNAL  ((op  JntrptJype  ()  =  OPCJNTRPT^REMO'IB)  &&  \ 

(opJntrpt_code  ()  =  AMSC^INTERFACE.SIGNAL)) 

#define  EST^CON  (primitive  ==  AMSC_AAL_ESTAB_Con) 

#defiDe  REL_IND  (primitive  —  AMSC_AAL_RELEASE_Ind) 

#define  REL.CON  (primitive  =  AMSC_AAL^RELEASE_Con) 

#defme  CALL^END  ((op JntrptJype  0  =  OPCJNTRPT_SELF)  &&  \ 

(op  Jntrpt_code  ()  ==  AMSC^TGEN.CALL.END)) 

/*  These  are  the  ams_traf__gen  self  interrupt  codes.  */ 

#defiDe  AMSC^TGEN^CALL^START  0 
#define  AMSC„TGEN_CALL_END  1 
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25 


#define  AMSC_TGEN_DATA^GEN  2 
#defineBADD__CALL^RESCHEDULE  5 
#define  BADD_CHECK_CHANNEL  6 


30 


/*  The  amsjrafjgen  process  will  output  trace  information  if  this  conditional  is  true,  *1 

#define  LTRACE_ACnVE  (debug_mode  &&  . 

(op  prg  odbjtrace  active  (“ams ")  II 
op_prg_odbJtrace__active  ("ams_traf  “)  II 
op^prg^odbjtrace  active  ( "ams_t ra f_gen  “))) 


\ 

\ 

\ 


#define  LTRACE_CONNECT_ ACTIVE  (op_prg_odb_ltrace_active  ( " connec t ")) 


35 


/*  Code  added  for  badd  *1 

#define  LTRACE^STATIC.PCR_ACTIVE 


#defiDe  LTRACE_CALL_GENERATOR„ACTIVE 


(op jprg_odbJtrace_active  ( “ sta t  ic_pcr ")) 

(op  prg  odbjtrace  active  ( "cal l_generator ")) 


40  #define  LTRACE_CALL_GEN_ACTIVE  (op_prg_odb Jtrace_active  ("cal  l_gen ")) 

#defiDe  LTRACE_CALL_RESCHEDULER_ACnVE  (op_prg_odb Jtrace__active  ("cal  l_res  ched  u  l  e  r " )) 

#deflQe  LTRACE_CALL_COMPLETE_ACTIVE  (op_prg_odb Jtrace  active  ("cal  l_c ompl  et e " )) 

45 

/*  Procedure  declarations.  *1 

void  badd_caII_gen__spurious_signaJ_handle  (); 

void  badd_call_gen_error  (); 


55 


Sta 

te  Variable  BioCk  I 

int 

Nmy_pro_id; 

int 

\dest_addr; 

int 

Npacket_si2e; 

int 

\AAL_type; 

5 

int 

^os_class; 

Lnt 

V^hanneLas  signed; 

int 

\debug_mode; 

int 

\to_aal_stream_index; 

double 

\int_arr_time; 

10 

double 

\calLwail_time; 

double 

\calLduration; 

double 

\peak_ceILrate; 

double 

Navg_rate; 

double 

\channel_delay; 

15 

char 

Npid_strmg  [128]; 

Objid 

Nmyjd; 

Objid 

\aaI_modu  I  e_id; 

Objid 

Nparent__obj_id; 

Ici* 

\aal_handle_iciptr; 

20 

Ici* 

VrhanneLiciptr; 
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Evhandle 

\next_packet_arrival; 

Evhandle 

\caILend_intrpt; 

Distribution* 

\int_arrival_distptr; 

Distribution* 

\caILduration_di  stptr; 

25 

Prohandle 

'^y_prohandle; 

Badd_Sch_Mod_Data*  Ninodule_data_ptr; 

AmsT_Traf_Contract*  Ntraf_con_ptr; 
AmsT_Neighbor_Data*  '^br_data_ptr. 

30 

/*  Code  added  for  BADD  */ 

int 

primitive; 

int 

badd_dest__addr. 

double 

start_time; 

5 

double 

badd_packet__size; 

double 

event_time; 

double 

end_sim_time; 

double 

cdv_tolerance; 

extern  int 

total_calls_generated; 

10 

extern  int 

totaI_calIs_received; 

Id* 

calLidptr; 

Ici* 

upper_handle_idptn 

Id* 

ifjciptr; 

Packet* 

pkptr; 

15 

AmsT_Traf_Contract*  tmp_traf_con_ptr; 

/*  End  code  added  for  BADD  *1 

20 

1  Function  Block  I 

void 

badd_call_gen_spurious_signal  handle  () 

{ 

Ici*  ifjdptr; 

5 

Ici*  release_if_idptr; 

int  primitive; 

Ici*  ILhandle^iciptr; 

Packet*  pkptr. 

10 

/*  This  procedure  handles  spurious  interrupts. 

*/ 

/*  Only  three  types  of  spurious  interrupts  can  be  accepted.  All 

*/ 

/*  others  must  result  in  an  op_sim  end().  These  three 

*/ 

/*  interrupts  are: 

*/ 

/*  I.  AnAALESTABInd. 

*/ 

15 

/*  2.  An  AAL  RELEASE  Con. 

*/ 

/*  3.  A  packet  arrival. 

FIN  (ams_traf_gen_spurious_signaI_handle  ()); 

*/ 

if  (SIGNAL) 
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20 


25 


30 


35 


40 


45 


50 


60 


65 


70 


75 


I 


{ 

/*  This  is  a  signal  from  the  AAL.  *1 

/*  Obtain  the  ICI  pointer.  *f 

if_iciptr  =  op^intrpt Jd  (); 

f*  Obtain  the  primitive  from  the  ICI.  */ 

op_ici_attrjget  (if_idptr,  "primitive ",  &priinitive); 

/*  Obtain  the  'lower  layer  handle'  from  the  ICI.  *1 


op_id_attr_jget  (if_idptr,  " lower  layer  handle",  &lLhancile_idptr); 

/*  Switch  on  the  'primitive' .  */ 

switch  (primitive) 

{ 

case  AMSC_AAL_ESTAB_Ind: 

{ 

/*  This  is  an  'establish  indication'  from  the  AAL.  */ 

if(LTRACE^ACTIVE) 

{ 

op_P**g_odb_print_iiiajor(pid_string,  "Received  spurious  AAL  ESTABLISH  Request  signal.", 
"Call  not  accepted. ",  "Sending  AAL  RELEASE  Request  signal .",  OPC_NIL); 

) 


/*  Set  the  'upper  layer  handle'  in  the  interface  *! 

/*  ICI  for  the  'establish  indication'  signal,  since  */ 

/*  the  lower  layer  expects  it  to  be  filled  in.  The  */ 

/*  ICI  is  not  destroyed,  since  this  is  a  forced  *1 

I*  interrupt  and  the  lower  layer  process  expects  *1 

f*  to  obtain  the  handle  from  the  ICI  when  the  */ 

/*  control  returns.  */ 

opJ<^L^ttr_set (if Jciptr,  "upper  layer  handle",  OPC^NIL); 

}*  Simply  send  an  AAL  RELEASE  Req  to  request  that  *1 

/*  the  connection  be  released.  */ 

release_if_idptr  =  opjci^create  (AMSCJNTERFACE_ICI); 


op  J^L^ttr^set  (release_if_iciptr,  - pr imi  t  i ve " ,  AMSC_AAL„RBLEASE_Req); 
op_*oi_attr_set (release_if_iciptr,  "lower  layer  handle",  ll_handle_iciptr); 
op_ici_install  (release_if_iciptr); 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  module.  */ 
opJntrpt__scheduIe_renjote  (op_sim_time  (),  AMSC„INTERFACE_SIGNAL,  aal_moduleJd); 

break; 

} 

case  AMSC_AAL_RELEASE_Con: 

{ 

/*  This  is  a  'release  confirm'  from  the  AAL.  *1 

if(LTRACE_ACTIVE) 

{ 

op_prg_odb_print_major(pid_string,  "Received  spurious  AAL  RELEASE  Confirm  signal.", 
"This  is  in  response  to  AAL  RELEASE  Request  terminating  spurious  connection. 

} 

/*  This  is  a  response  to  our  earlier  '  release  *! 

/*  request'  which  was  a  response  to  the  *1 
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i*  spurious  ’estab  indication’ . 

I*  Do  nothing  other  than  destroy  the  ICL 
op_ici_destroy  (if Jciptr); 


/*  This  is  some  other  completely  unexpected 
I*  signal.  Issue  error  message  and  terminate 
/*  simulation. 

op_sim__end (“Received  unexpected  signal. 


else  if  (op  Jntrpt_type  ()  —  OPC_INTEOT'_STRM) 

{ 

/*  This  is  a  spurious  packet  arrival.  The  amsjraf_gen  *l 

/*  just  destroys  this  packet.  */ 

if(LTRACE^ACriVE) 

{ 

op_prg_odb__print__iiiajor  (pid_strmg,  "Received  spurious  DATA  paclcet. 
“Destroying  the  packet OPC_NIL); 


/*  Get  the  packet  jromt  the  stream  and  destroy  it. 
pkptr  =  op_pkjget  (op  Jntrpt_strm  ()); 
op_pk_destroy  (pkptr); 


/*  This  is  some  other  completely  unexpected 
i*  interrupt.  Issue  error  message  and  terminate 
/*  simulation. 

op_sim_end(“ Received  unexpected  interrupt. 

} 


120  void 

badd_call_gen_en'or  (msgO,  msgl,  msg2) 
char*  msgO; 

char*  msgl; 

char*  msg2; 

125  { 

/**  Print  an  error  message  and  exit  the  simulation.  **/ 

FIN  (badd_caII_gen_error  (msgO,  msgl,  msg2)); 

op_sim_end ("Error  in  badd_call_generator  process; 
130  msgO,  msgl,  msg2); 
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IDiaanostic  Block  1 

5 

/*  Display  connection  information,  if  requested.  *1 
if(LTRACE_CONNECT  ACTIVE) 

{ 

/*  Print  information.  *1 

ams_neighbor_data_print  (nbr_data_ptr,  ams  neighbor  desc  print  noop); 

} 

forced  state  JNIT  | 

attribute 

value  ‘ 

default  value 

name 

INIT 

string 

st 

enter  execs 

(See  below.) 

textiist 

exit  execs 

(empty) 

textiist 

(empty) 

status 

forced 

toggle 

unforced 

I 

I 


r  g/Kgr  gXgCy::  : xllNI  I 


/*  New  process  created  for  BADD  ATM  Simulation.  */ 

/*  This  process  generates  the  call  data  when  the  call  is  scheduled 
!*  for  a  channel.  ♦/ 


5  /*  Determine  if  the  simulation  is  in  debug  mode,  traces  are  only  *! 

I*  enabled  in  the  debug  mode.  */ 

debug_mode  =  op_siin_debug(); 

/*  Determine  the  prohandle  and  processjd  for  this  instances  of  a  */ 

10  /*  badd_call ^generator.  *1 

niy_prohaiidle  =  op_pro_self(); 
my^projd  =  op_proJd(my_prohandIe); 

if  (my^rojd  ==  OPC^PRO_ID_IN  VALID) 

15  badd_caII_gen_error(- Unable  to  get  own  process  id",  OPC_NIL,  OPC_NIL); 

parent_obj_id  =  op_pro_mod_objid(my_prohandle); 


20 


/*  Initialize  the  process  ID  display  string  */ 

sprintf(pid_string, -badd_call_gen  PID  (%d) my_proJd); 


25 


/*  Access  the  module  memory  data  structure  *f 

modiile_dala_4)tr  =  (Badd_Sch_Mod_Data*)op_pro  modmem_acce$$(); 
if  (module_data_ptr  =  OPC_NIL) 

badd_call_gen_error(“ Unable  to  get  module  memory OPC_NIL,  OPC_NIL); 


nbr_data_ptr  =  module_data_ptr->md_neighbor_data_ptr, 
channel_delay  =  moduIe_data_ptr->md_channel_deIay; 


30 


f*  Access  the  argument  memory  and  get  the  call  descriptor 
/*  information.  *l 

call  Jciptr  =  (Ici*)op_pro_argmeni_access(); 


35 


if  (LTRACE.C  ALL_GENER  ATOR.ACTIVE) 

{ 
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printf("In  badcl_call_gen.  init :  my_prohandle  =  %x.\n",my_prohandIe); 
printf("In  badd_call_gen.  init :  call_iciptr  =  . \n ",  call_iciptr); 

printf("In  badd_call_gen.  init ;  pro_id  t:  %d.  \n",my_pro_id); 

} 

40 

if  (calLiciptr  =  OPC^NIL) 

badd_call_gen_error( " I n  badd_cal  l_gen.  init :  unable  to  get  call_iciptr. ",  OPC_NIL,  OPC_NIL); 

((opJ^Lattrjget  (calLiciptr,  "interarrival  time", &mt_arr_time)  =  OPC_COMPCODE_FAILURE)  II 
45  (op jci_attr_5et (calLiciptr,  "packet  size", &packet_size)  =  OPC_COMPCODE_FAILURE)  ii 

(op Jci_attr_get  (calLiciptr,  "call  wait  time",  &calLwaiLtime)  =  OPC_COMPCODE_FAILURE)  II 
(opJcLattr^get  (calLiciptr,  "call  duration ",  &caU_duration)  =  OPC_COMPCODE_FAILURE)  11 
(op Jci_attr jget  (calLiciptr,  •  dest  a dd  r " ,  &desLaddr)  —  OPC_COMPCODEJFAILURE)  II 

(opjcLattr jget  (calljciptr,  -  QoS  class",  &qos_class)  =  OPC_COMPCODE_FAILURE)  II 

50  (op Jci^attr^et  (calljciptr,  - AAL  type " ,  &AAL_.type)  =  OPC^COMPCODE.FAILURE)  II 

(op JcLattrjget  (calljciptr,  "  channel  ass  i gned " ,  &channeLassigned)  =  OPC_COMPCODE_FAILURE)  II 

(opJcLattr_get (calljciptr,  "peak  cell  rate", &peak_celLrate)  =  OPC__COMPCODE_FAILURE)) 
badd_calI_gen_eiTor(“In  start  call,  unable  to  get  values  from  call_iciptr“,  OPC_NIL,  OPC_NIL); 

55  if(LTRA(:E^CAlX_.GENERATOR^ACTIVE) 

{ 

printf("In  badd_call_gen.  init ;  packet^size  =  %d.\n",packeLsi2e); 
printf("In  badd_call_gen.  init ;  dest_addr  =  %d . \n",  desLaddr); 
printf("ln  badd_call_gen.  init ;  AAL_type  =  %d.  \n",  AAL_type); 

60  printf("ln  badd_call_gen.  init ;  qos_class  =  %d. \n",  qos_class); 

printf("ln  badd_call_gen.  init ;  int_arr_time  =  %f .  \n",  inLarrJime); 
printf("In  badd_call_gen.  init ;  call_wait_time  s  %f .  \n",  calLwaitJime); 
printf("In  badd_call_gen.  init ;  call_duration  =  %f .  \n",  calLduration); 
printf("ln  badd_cal l_gen. init ;  channel  assigned  =  %d . \n", chaimeLassigned); 

65  } 

/*  Release  the  memory  for  this  call  descriptor  */ 
opJci_dcstroy(calLiciptr); 

70  /*  Load  in  the  packet  interarrival,  call  wait  and  call  duration 
/*  distributions. 

mLarrival_disQ)tr  =  op_dist Joad  ( "constant " ,  inLarrJime,  0.0); 
caILduration_dis^tr  =  op_distJoad  ("  constant ",  calLduration,  0.0); 

75  /*  Code  added  for  BADD  */ 
badd_packeLsize  =  packeLsize; 

peak^cell jate  =  (1.0  /  inLarrJinie)  *  (badd_packet_size  /  AMSC_ATM_CEIX_DATA_SIZE); 

if  (LTRACE_CALL^GENER  ATOR^ACTIVE) 

80  { 

printf("In  badd_call_gen,  Init;  Peak_Cell_Rate  =  % f . \n " , peakjelLrate); 
printf("\tlnt_Arr_Time  =  %f,  \tPacket_Si2e  =  %d.\n",  inLarr^time,  packet  size); 

} 

85  /*  Code  for  getting  the  simulation  duration  */ 

o p J ma j im_attr^et(OPC JM A_DOUBLE,  "duration", &end jim_tiine) ; 

if  (LTRACE_CALL_GENERATOR_ACTIVE) 

{ 

90  printf("In  badd_call_gen,  Init;  end_sim_time  =  %f .  \n“,  endjimjime); 

} 

/*  End  Code  added  for  BADD  */ 

/*  Use  the  default  Cell  Delay  Variation  ( CDV)  tolerance  for  the  */ 


*! 

*f 
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95 

/*  specific  QoS  class. 

cdv_tolerance  =  ams_CDV_toIerance_default_obtain  (qos_cIass); 

*/ 

/*  Create  a  traffic  contract  for  calls  originating  from  this  src. 

/*  There  is  no  return  traffic,  but  allocate  a  bit  (.1  *  PCR )  of 

*1 

100 

/*  bandwidth  anyway. 

traf_con_ptr  =  ams_traffic_contract__create  (peak_celLrate, 
peak_ceILrate  *  0.1,  cdv_toIeraiice,  cdv_tolerance); 

/*  Initialize  the  AAL  module  object  ID  and  aal  stream  index.  */ 

105 

nioduIe_id  =  niodiile_data_ptr->md_aal_moduIe_id; 
to„aal_stream_index  =  module_data_ptr->md_to_aal_streain_index; 

if  (LTRAC^_C  AIX_GENERATOR^ACTIVE) 
printf("In  badd_call_gen;  aal_inodule_id  =  %d. \n ", aal_module_id); 

110 

/*  Generate  PID  display  string. 

sprintf  (pid^string,  “badd_call_gen  PID  (%d) ", op^projd  (op_pro_self  ())); 

*1 
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/*  Start  a  call  by  issuing  a  call  open  request  to  the  ATM 
/*  adaptation  layer. 

if  (LTRACE_ACnVE) 


{ 


*/ 

*/ 


op_prg_odb_print_major(pid_string,  “Initiating  call  SETUP.", 

“Sending  AAL  ESTABLISH  Request  signal OPC_NIL); 


10 


/*  Make  a  copy  of  the  traffic  contract,  since  the  lower  layers 
!*  are  responsible  for  destroy  the  data  structure. 
tmp_traf_con_ptr  =  ams_traffic_contract_copy  (traf_con_ptr); 


upper_handlejciptr  =  opJci_create(  "badd_ca  1  l_gen_handl  e " ); 


*! 

*! 
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op_ici_attr_set (upper_handle_iciptr,  "cal l_gen_prohandle ", &my_prohandIe); 


20 


25 


30 


/*  Create  and  set  the  fields  in  the  interface  ICI.  */ 

if Jciptr  =  opJci_create  (BADD_CALL_GEN_IF_ia); 
op_icMnstalI  (ifjciptr); 

op_ici_attr_set (if_iciptr,  "primitive ",  AMSC_AAL_ESTAB_Req); 
op_ici_attr_set  (if_iciptr,  "address " ,  dest_addr); 

opJci_attr_set  (if Jciptr,  "called  party  SAP",  AMSC_AAL_SAP_ANY); 

opJci_attr__set  (if Jciptr,  "QoS  class ",  qos_class); 

opJci_attr_set  (if JcipiT,  "upper  layer  handle",  upper_handle Jciptr); 

op Jci_attr_set  (if  Jciptr,  "AAL  type  “ ,  AAL_type); 

opJci_attr_set  (if Jciptr,  "traffic  contract ",  tmp_traf_con_ptr); 

opJci_attr_set  (if Jciptr,  " badd_ca  1  l_gen_pro_i d " ,  my_pro Jd); 

opJci_attr_set  (if Jciptr,  "badd_cal  l_gen_channel_id",  channel_assigned); 

/*  Code  added  for  BADD  *l 


35 


if  (LTOACE^CALL^GENER  ATOR.ACriVE) 

{ 

printf("In  badd_call_generator,  start;  starting  call  to  dest  %d .  \n",  dest_ad<ir); 
printf(“In  badd_call_generator,  start;  aal_module_id  =  %d .  \n",  aal_moduIeJd); 

}  f*Endif(LTRACESALL_GENERATOR_ACTJVE)  *f 


40 


/*  End  of  code  added  for  BADD  *f 

I*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL 
/*  module. 


*/ 

*J 


op  Jntrpt_schedule_remote  (op_sim_time  (),  AMSC_INTERFACE_SIGNAL,  aal^modulejd); 


1  transition  Start  ->  EstCon  I 
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if  (LTRACE.C  ALL_GENERATOR_ACnVE) 

{ 
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printf("In  cal l_gen.Est Con. enter  execs . \n",  OPC_NIL,  OPC_NIL); 

} 


\  exit  execs  EstCon  I 

5 

/*  This  state  expects  three  possible  interrupts:  */ 

/*  1.  Establish  Confirm  signal.  */ 

/*  2 .  Release  Indication  signal.  */ 

!*  3.  Spurious  signal.  */ 

if(LTRACE^CALL  GENERATOR  ACTIVE) 

{ 

printf("In  badd__call_gen. EstCon:  call^gen  restarted. \n"); 

} 

/*  Determine  what  signal  arrived.  *} 

/*  Obtain  the  interface  ICJ  pointer.  *! 

ifjciptr  =  op jntrpt Jci  (); 

10 

15 

!*  Obtain  the  primitive  value.  *f 

(if_iciptr,  "primitive",  &primitive); 

20 

/*  Switch  ojfthe  primitive  value.  */ 

switch  (primitive) 

{ 

caseAMSC_AAL_ESTAB  Con: 

{ 

/*  The  signal  is  an  AAL  ESTABLISH  Confirm  signal.  */ 

/*  The  connection  has  been  established.  */ 

if(LTRACE_ACTIVE) 

op_prg__odb_prmt_major (pid_string,  "Received  AAL  ESTABLISH  Confirm  signal.", 

"Connection  established.  ",OPC_NIL); 

25 

30 

i*  Obtain  the  lower  layer  handle.  *l 

'  op_ici_attr_get  (if_iciptr,  " lower  layer  handle",  &aal_handle_iciptr); 

/*  Destroy  the  ICI.  */ 

op_ici_destroy  (ifjciptr); 

35 

/*  Schedule  the  call  end  event.  *! 

call_end_intrpt  =  opJntrpt_scheduIe_self  (op_simJime  ()  +  , 

op_dist^outcome  (calLduration_distptr),  AMSC_TGEN_CALL_END); 

40 

/*  Schedule  the  next  arrival.  */ 

next_packet_arrival  =  opJntrpt_scheduIe_seIf  (op_sim_time  ()  + 

op_dist_outcome  (int_arrival_distptr),  AMSC_TGEN_DATA_GEN); 

if  (LTKACE^^C  ALL.GENERATOR^ACTIVE) 

( 

start_time  =  op_simJime  ()  +  op_dist_outcome  (int_ajTivaLdistptr); 
printf("ln  badd_call_gen. EstCon;  start  time  =  %f ,  \n",  start  time); 

} 

45 

50 

break; 

) 

case  AMSC_AAL_RELEASE_Ind: 

/ 

i 

/*  The  signal  is  an  AAL  RELEASE  Indication  signal.  */ 
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55 


60 


65 


70 


/*  The  connection  has  been  terminated.  *! 

if(LTRACE_ACTIVE) 

op__prg_odb_print_major (pid_string,  “Received  AAL  RELEASE  Indication  signal.", 
"Connection  terminated. ",  OPC_NIL); 


/*  Destroy  the  ICI.  *1 

op_ici_destroy  (ifjciptr); 
break; 

} 

default: 

{ 

/*  This  is  a  spurious  signal.  */ 

prmtf("In  badd_call_gen. EstCon  state;  inside  switch  statement . \n"); 
badd_call_gen_spurious_signaJ_handle  (); 
break; 

} 

} 
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if  (LTRACE.C  ALL^GENERATOR^ACTIVE) 


{ 

printf(“In  call_gen,  received  signal 

} 


to  start  sending  data .  \n ",  OPC_NIL,  OPC_NIL); 


exit  execs  datacren  ^  i:  : 


/*  This  state  expects  four  possible  interrupts:  *} 

I*  L  An  AAL  RELEASE  Indication  signal.  */ 

1*2.  A  Spurious  signal.  */ 

f*  3.  A  call  end  interrupt.  *} 

5  /*  4.  A  generate  data  interrupt.  */ 


if(LTRACE_CALL_GENERATOR  ACTIVE) 

{ 


10  } 


printf("ln  badd_call_gen.  data  gen -exit  execs.  \n"); 


15 


20 


25 


30 


/*  Determine  if  this  is  an  AAL  signal. 
if(SIGNAL) 

{ 

/*  Obtain  the  interface  I  Cl  and  enclosed  primitive. 
if_iciptr  =  op_intrptJci  (); 

(if_iciptr,  "primi t  ive ",  &primitive); 

/*  If  the  primitive  is  'release  indication’ , 
f*  cancel  the  call  end  and  data  gen  intrpts; 
f*  otherwise,  the  primitive  indicates  a 
I*  spurious  signal. 

if  (primitive  =  AMSC_AAL_RELEASE_Ind) 

/*  This  is  a  ’release  indication’  signal. 
if(LTRACE^ACnVE) 

<*PJP*’g_o<lb_print__major (pid_string,  "Received  AAL  RELEASE 
"Connection  terminated. ",  OPC_NIL); 


*/ 


*} 


*l 

*1 

*l 

*1 


*/ 

Indication  signal.". 


35 


40 


I 


/*  Cancel  the  ’call  end’  and  ’generate  data’  events. 
op_ev_cancel  (next_packet_aiTival); 
op__ev_canceI  (cali_end_intrpt); 

!*  Destroy  the  ICI. 
op_ici_destroy  (if_iciptr); 

} 

else 

{ 

/*  This  is  a  spurious  signal. 
ams_traf_gen_spurious_signal_handIe  (); 

) 

} 


*/ 


*! 
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/*  Determine  whether  this  interrupt  is  a  self  interrupt  *f 

I*  that  indicates  the  end-of-call.  */ 

elseif(CALL^END) 

{ 

/*  This  is  a  self  interrupt  that  indicates  the  end-of-call.  */ 

if(LTRACE_ACriVE) 

{ 

op_prg_odb_print__major  (pid^string,  -Initiating  call  END .  - , 

"Sending  AAL  RELEASE  Request  signal OPC_NIL); 


/*  Cancel  the  current  packet  arrival  interrupt.  *l 

op_ev_cancel  (next_packet„amval); 

/*  Notify  the  AAL  that  the  call  is  complete.  */ 

if.iciptr  =  opJci__create  (BADD_CALL_GEN^IF_ICI); 
op Jci_attr__set  (ifjciptr,  -primitive-,  AMSC_AAL_RELEASE_Req); 
op_*ci_attr_set  (if_iciptr,  - 1 owe r  1  ayer  handle-,  aal_handle_iciptr); 

(tf-iciptr,  "badd_call_gen_channel_id",  channel_assigned); 
opjcijnstall  (iLiciptr); 


if  (L'mACE_CALL_GENERATOR_.ACTIVE) 


printf("In  call_gen.data_gen:  call  completed  for  channel  %d . \n-,  channel_assigned); 


/*  Send  a  remote  interrupt  that  will  carry  the  ICI  to  the  AAL  */ 

/*  module.  */ 

opjntrpt_scbedule_remote  (op_simJime  (),  AMSC^INTERFACE^SIGNAL,  aal__moduIeJd); 

) 

else  if  (opJntrpt_type  ()  —  OPCJNTRPT_STRM) 

{ 

/*  This  is  a  spurious  signal.  */ 

badd_call_gen_spurious_signaI_handle  (); 

} 

else 

{ 

/*  This  is  a  ‘generate  data‘  event.  */ 

if(LTRACE^ACnVE) 

oP^P>‘g_odb_priiit_major(pid_string,  -Sending  DATA . " ,  OPC.NIL); 

/*  Install  the  AAL  handle  ICI.  */ 

opJcMnstall  (aal_handle_iciptr); 

/*  Create  a  data  packet  and  send  it  to  the  AAL.  ♦/ 

pkptr  =  op_pk_create  (packet_size); 

if  (LTRACE^CALL^GENERATOR^ACTIVE) 


f 


} 


prmtf(-In  badd_call_gen.data  gen;  pk  created  with  addr  %d. \n",  dest_addr); 

printf("ln  badd_call_gen.data  gen;  pk  created  with  size  =  %d . \n", packet^size); 

printf(-In  badd_call__gen.data  gen;  pk  send  to  strm  index  %d.  \n-, to_aaJ_streani^index); 


op_pk_send  (pkptr,  to_aaJ_stream_index); 
/*  Schedule  the  next  arrival. 
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next_packet_anival  =  opJntrpt_schedu!e_self  (op_sim_time  ()  + 

op_dist_outcome  (mt_aiTival_distptr),  AMSC_TGEN_DATA_GEN); 
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if  (LTRACE.C  ALL_GENERATOR_ACnVE) 

{ 

printfCIn  cal l_gen. RelCon. enter  execs .  \n",  OPC_NlL,  OPC_NIL); 

} 
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Imit  execs  RelCon  .  .  1 

/*  This  state  expects  two  possible  interupts:  */ 

1*  I.  An  AAL RELEASE  Confirm  signal.  */ 

1*2.  A  spurious  signal.  *f 

5 

/*  Determine  what  signal  arrived.  */ 

}*  Obtain  the  interface  ICI  and  enclosed  primitive.  */ 

if Jciptr  =  op  Jntrpt_ici  (); 

iO 

op_ici_attrjget  (if_iciptr,  "primitive",  &priinitive); 

15 

/*  If  this  is  a  *  AAL  RELEASE  Confirm'  signal,  do  nothing;  */ 

}*  otherwise,  this  is  a  spurious  signal.  */ 

if  (primitive  =  AMSC  AAL  RELEASE  Con) 

{ 

20 

l*printf["In  call‘generatorJielCon:  Peak  Cell  Rate  =  %f.\n",peak  cell  rate);  *1 
f*  This  is  a  ’AAL  RELEASE  Confirm’  signal.  */ 

if(LTRACE_CALL^GENERATOR  ACTIVE) 

( 

oP_Prg_odb_print__iiiajor(pid_string,  "Received  RELEASE  Confirm  signal.", 

"Call  END  complete. ",  "Connection  terminated .",  OPC_NIL); 

25 

/*  Destroy  the  ICI.  */ 

op  ici  destroy  (if  iciptr); 

} 

}  ■ 
else 

f 

30 

1 

/*  This  is  a  spurious  signal.  *f 

badd__call_gen  spurious  signal  handle  (); 

} 
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unforced  state  reschedule  1 
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if  (LTRACE^C  ALL_GENERATOR_ACTrVE) 

{ 

printf("In  cal l_gen.  reschedule. enter  execs.  \n",  OPC_NIL,  0PC_N1L); 

} 

ifjciptr  =  op Jci_create  ( "  ba  dd_ca  1 1  _re q_ i  f c  i  - ); 
opJcUnstall(ifJdptr); 

op_ici_attr_set  (if_iciptr,  "interarrival  time",  int_arr__time); 
op_ici_attr_set  (if_iciptr,  "packet  size",  packet_si2e); 

(if_iciptr,  "call  wait  t ime " ,  call_wait_time); 
op_ici_attr_set  (if_iciptr,  "call  durat  ion",  calI_duration); 
op Jci_attr_set  (ifjciptr,  "  des t  a dd r " ,  dest_addr); 
op Jci_^ttr_set  (if Jciptr,  -QoS  class ",  qos_class); 
op Jci_attr_set (if Jciptr,  "AAL  type",  AAL_type); 

"peak  cell  rate", peak_ceILrate); 
op Jci_attr_set  (ifjciptr,  "  cha nne  1  as  s  i  gne d " ,  chaiuiel_assigned); 

op jDtrpt_scheduIe_remote(op_simJiine()  +  chaimel_delay,  BADD_CALL_RESCHEDULE,  parent^obj^id); 

/*  Need  to  send  intrpt  to  run  a  reschedule  event  *1 
if  (LTOAOE^CALL.RESCHEDULER.ACTIVE) 

{ 

oP_Pr8_odb_P''>oL*“*jor(pid_string,  "Call  Terminated,  Call  Rescheduled.", 

"Destroying  call_gen  process OPC_NIL); 

} 


/*  Send  intrpt  to  check  for  next  call  on  this  channel  *1 
channel Jciptr  =  opJci_create("badd_channel_ici  "); 
opJciJnstaU(channel_iciptr); 

op Jci_attr_set  (channel  Jciptr,  "channel  number  - ,  channel_assigned); 
if  (LTRACE.CAIX^RESCHEDULER,  ACTIVE) 

{ 

printf("In  call_gen.call_done,  channel  released  =  %d . \n", channel_assigned); 

op  Jntrpt_scheduIe__remote(op_sim_ti me(),  B ADD_CHECK_CHANNEL,  parent_obj Jd); 

f*  This  process  destroys  itself  since  the  call  is  released  *f 
if  (op_pro_destroy(my_prohandle)  =  OPC_COMPCODE_FAILURE) 


badd_caII_gen_eiTor(- Unable  to  terminate  call_gen  process  OPC_NIL,  OPC^NIL); 


188 
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r execs  'Call 

if(LTRACE^CALL^GENERATOR  ACTIVE) 

{ 

op_prg_odbjprint__major(pid_string,  "Call  Successfully  Completed.", 

"Destroying  call_gen  process  OPC  NIL); 

) 

5 

10 

/*  Send  intrpt  to  schedule  next  call  *! 

channeljciptr  =  opJci_create("badd_channel_ici "); 

opJciJnstall(chamieLiciptr); 

op  ici  attr  set  (channeljciptr,  "channel  number" ,  channeLassigned); 
if(LTRACE^CALL^COMPLETE  ACTIVE) 

{ 

printf("In  call_gen.call_done,  channel  completed  =  %d.  \n",  channel_assigned); 

1 

15 

; 

opJntrpt_schedule_remote(op_simJime(),  BADD_CHECK_CHANNEL,  parent_objJd); 

This  process  destroys  itself  since  the  call  is  completed  *f 
if  (op_pro__destroy(my_prohandle)  =  OPC_COMPCODE_FAILURE) 
r 

20 

i 

badd_call_gen_en:or(" Unable  to  terminate  call  gen  process  OPC  NIL,  OPC  NIL); 

) 
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ExtemalFUe  Set  | 

attiibuie 

value 

default  value 

external  file  set 

badd  functions 

tvoed  file 

Process  Model  Comments  _ _ _ 

General  Process  Description: 


The  badd_caILscheduler  schedules  and  manages  all  static  channel 
assignments  tor  the  BADD  network.  This  model  schedules  calls  by  assigning 
new  calls  to  the  channel  with  the  least  number  of  calls  current  scheduled. 

ICI  Interfaces: 

badd_calLrecLifJci 

badd_call_genjf_ici 

Packet  Formats: 

None. 

Statistic  Interfaces: 

None 

Process  Registry: 

Published  Attributes  and  Expected  Attributes:  None 
Restrictions: 

None 


Process  Modef  Attributes  I 

Attribute  dest  addr  properties 
Property 

^atue 

Default  Value: 

NONE 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  destination  of 
the  call. 

Symbol  Map: 

Symbol  Value 

NONE  -1 

Allow  other  values: 

YES 

Attribute  scheduler  delay  properties 
Property 

Value 

Default  Value: 

0.0 
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Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Comments: 

The  maximum  time  in  seconds 
between  scheduler  events. 

I  Attribute  transmission  delay  properties 

Property 

Value 

Default  Value: 

0.25 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Attribute  channel  delay  properties 

Property 

Value 

Default  Value: 

7.681  E-05 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Comments: 

The  delay  between  calls  on 
the  same  channel. 

Attribute  calls  pending  properties 

Property 

Value 

Default  Value: 

0 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

The  maximum  nurfiber  of  calls 
to  store  in  the 
calisjpending  list  before 
running  a  schedule  process. 

Process  Model  Interface  Attributes 

Attribute  begsim  intrpi  properties 

Property 

Value  ■  •  ■ 

fnhent 

Assign  Status: 

Initial  Value: 

hidden 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  a  ’begin  simulation 

Interrupt’  is  generated  for  a  processor  module's  root 
process  at  the  start  of  the  simulation. 
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Symbol  Map: 

NONE 

YES 

Attribute  endsim  intrpt  properties 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  an  ’end  simulation 

interrupt’  is  generated  for  a  processor 
process  at  the  end  of  the  simulation. 

module’s  root 

Symbol  Map: 

NONE 

YES 

Attribute  feiJure  intipfs  properties 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  failure  interrupts 
are  generated  for  a  processor  module’s  root  process 
upon  failure  of  nodes  or  links  In  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  intrpt  interval  properties 
Property 

•  Value  ■  ■ 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle  double 

N/A 

Attribute  Description: 

Private 

N/A 

Units: 

sec. 

YES 

Comments: 

YES 

Symbol  Map: 

This  attribute  specifies  how  often  regular  interrupts 
are  scheduled  for  the  root  process  of  a  processor  module. 

NONE 

YES 

Attribute  priority  properties 

Prooertv 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

0 

N/A 

Default  Value: 

0 

YES 

Data  Type: 

integer 

N/A 

Attribute  Description: 

Private 

N/A 

Low  Range: 

-32767  inclusive 

YES 

High  Range: 

32767  inclusive 

YES 
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Comments: 


Symbol  Map: 


Attribute  recovery  intipts  properties 

Property _ 

Assign  Status: 
initiai  Vaiue: 

Default  Value: 

Data  Type: 

Attribute  Description: 

Comments: 


Symbol  Map: 


YES 

This  attribute  is  used  to  determine  the  execution  order 
of  events  that  are  scheduled  to  occur  at  the  same 
simulation  time. 

NONE  YES 


Value _ Inherit 

hidden 

disabled  N/A 

disabled  YES 

enumerated  N/A 

Private  N/A 

YES 

This  attribute  specifies  whether  recovery  interrupts 
are  scheduled  for  the  processor  module’s  root  process 
upon  recovery  of  nodes  or  links  in  the  network  model. 
NONE  YES 


Attribute  super  priority  properties  . 
Property 

Value"- ■ 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 

of  events  that  are  scheduled  to  occur  at  the  same 
simulation  time. 

Symbol  Map: 

NONE 

YES 

Process  Model  Simulation  Attributes 


Attribute  class_A_CDV_tolerance  properties 
Property  Value 


Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  A  cells 

may  experience. 

Attribute  class_B_CDV_tolerance  properties 
Property  Value 


Default  Value:  0.0 
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Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 

Service  (QoS)  class  B  cells 
may  experience. 

1  Attribute  class_C_CDV_talerance  properties 

Prooertv 

Vatue 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 

Service  (QoS)  class  C  cells 
may  experience. 

1  Attribute  class_DjCDy_tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  D  cells 
may  experience.  . 

I  Header  Block  I 

#iDClude  "/usr/local/mil3_dir/3 .O.A_DL5/models/std/atm/ams_interfaces.h" 

#iDclude  "/usr/local/mil3_dir/3  .O.A_DL5/models/std/atm/anis_aal_interfaces.h“ 

#iDclude  "/usr/work:/benton/op_code/badd_interface.h" 

5 

f*  These  are  transition  conditions.  *1 

#define  SIGNAL  ((opjntrptjype  ()  =  OPC_INTRPT_REMOTE)  &&  \ 

(opJntrpt_code  ()  =  AMSC_INTERFACE^SIGNAL)) 

10 

#denne  CALL_REQ_SIGNAL  ((opJntrpt_type  Q  =  OPC_INTRPT_REMOTE)  &&  \ 

(op_intrpt__code  ()  =  BADD^REQUEST^SIGNAL)) 

15 

#define  AAL_CALL_SETUP  ((SIGNAL)  &&  \ 

((primitive  ==  AMSC_AAL_ESTAB_Req)  11  \ 

(primitive  =  AMSC_AA_ESTAB_Ind))) 

#denne  SAAL.SIGNAL  ((op  Jntrpt  Jy pe  ()  =  OPCJNTRPT_REMOTE)  ScSc  \ 

(op  intrpt  code()  =  AMSC^SAAL„SIGNAL)) 
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#define  AAL_DATA 


#defineEST_CON 


#defmeREL_IND 


25  #defiDeREL_CON 


#defineCALL^START 


30  #defineCALL^END 


#define  SCHEDULER 


#defme  RESCHEDULE 


(op  jntrpt_type  ()  =  OPC_INTRPT_STRM) 

(SIGNAL  &&  (primitive  ==  AMSC_AAL^STAB„Con)) 

(SIGNAL  &&  (primitive  =  AMSC.AAL^RELEASE^Ind)) 

(SIGNAL  &&  (primitive  =  AMSC_AAL^RELEASE_Con)) 

((op  intrpt  type  ()  =  OPCJNTRPT^SELF)  &&  \ 

(op  Jntrpt3:ode  ()  =  BADD_CALL„SCH_START)) 

((op Jntrpt  Jype  ()  ==  OPC__INTRPT^SELF)  &&  \ 

(op  Jntrpt^code  ()  ==  AMSC^TGEN^CALL_END)) 

((opJntrpt_type  Q  =  OPCJNTRPT_SELF)  &&  \ 

(op_intrpt_code  ()  =  BADD_CALL_SCHEDULER)) 

((opjntrptJype()  =  OPC_INTRPT^REMOTE)&&  \ 
(op Jntrpt_code  Q  =  BADD_CALL_RESCHEDULE)) 


#define  CHECK_CHANNEL_SIGNAL  ((opjntrpt  type  ()  OPC^INTRPT^REMOTE)  &&  \ 

40  (op_mtrpt_code  0  =  BADD_CHECK_CHANNEL)) 

#defineWAIT_CALL^DURATION  ((op  intrpt^type  ()  =  OPC_INTRPT_SELF)  &&  \ 

(opjntrpt_code  ()  =  AMSC_TGEN^WAIT_CALL^DURATION)) 

45  #derine  END_SIMULATION  ((opjntrptjype  ()  =  OPC_INTRPT_ENDSIM)) 

#define  NEIGHBOR^NOUFY  ((op  Jntrpt Jype  ()  =  OPC^INTRPT^REMOTE)  &&  \ 

(opjntrpt^code  ()  =  AMSC_NEIGHBOR_NOTIFY)) 

50  #define  NOUFY^COMPLETE  (ams_neighbor_notifyjs__complete  (nbr_data_ptr)  =  OPC_TRUE) 

/*  These  are  self  interrupt  codes.  *1 
#define  BADD_CALL_SCH_START  0 

#define  AMSC.TGEN^CALL.END  1 

55  #defineAMSC_TGEN_DATA_GEN  2 

#defineAMSC_TGEN_WAIT^CALL_DURATION  3 
#define  BADD^CALL_SCHEDULER  4 

#defineBADD_CALL_RESCHEDULE  5 

#define  BADD_CHECK_CHANNEL  6 

60  #defineMAX_CHANNELS  1024 

#defme  MAXSIZE  11 


/*  The  scheduler  process  will  output  trace  information  if  these  conditional  are  true.  */ 

#deriDe  LTRACE_ACnVE  (debug_mode  &&  \ 

65  (op_prg_odbjtrace_active  (“ams“)  II  \ 

op_prg_odb  Jtrace  active  ( "  a  ms_t  r a  f  “ )  II  \ 

op_prg_odb Jtrace_active  ( •  ams_t  ra  f_gen " ))) 

#define  LTRACE_CONNECT_ACTIVE  (op_prg_odb_Itrace_active  (  "connect")) 

70 

#define  LTRACE_CALL_SCHEDULER_ACTIVE  (op_prg_odb_ltrace_active  (“call  _sche<au  1  e  r " )) 
#derine  LTRACE_CALL_SCH_ACTIVE  (op_prg_odbJtrace_active  (  "call_sch")) 

75  #define  LTRACE_CALL_DISP_ACTrVE  (op_prg_odb_ltrace_active  ( "  ca  1  l_d i sp " )) 
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#define  LTRACE_CALL_CHANNELS_  ACTIVE  (op_prg_odb_ltrace_acti  ve  ("cal  l_channe  Is")) 

#define  LTRACE„CALL_TIMER_  ACTIVE  (op_prg_odb  Jtrace_active  ("cal  l_t  imer ")) 

fdefine  LTRACE_CALL_RESCHEDULER_ACTrVE  (op_prg_odb_ltrace_active  ("cal  l_reschedulGr ")) 


85 


/*  Function  declarations.  */ 

void  badd_calLsch_nbr_intrpt_proc  (); 

void  badd__call_sch_spurious_signal_handIe  (); 

void  badd_calLsch_Iist_print  (); 

void  badd_caILsch_error  (); 


Sta 

te\^rial>le  Block 

int 

Ndebug_mode; 

int 

\packet_size; 

int 

\dest_addr; 

int 

\AAL_type; 

5 

int 

\qos_class; 

int 

'^o_aaJ_stream_index; 

int 

^o_req_slream_index; 

int 

Nsch_channel_count; 

int 

\number_calls_pending; 

10 

int 

Ninax__calls_pending; 

double 

\avg_rate; 

double 

\channel_delay; 

double 

%ans_delay; 

double 

\time_to_next_scheduien 

15 

double 

\snd_siin_time; 

char 

'^id_string  [128]; 

Objid 

Nmyjd; 

Objid 

\aal_nioduleJd; 

Objid 

Nreq_moduIe_id; 

20 

List* 

\calls_pending; 

List* 

\calls_scheduled; 

List* 

\static_channels; 

FILE* 

\ou^ut_fiIe; 

FILE* 

\DUtput_calls; 

25 

Ici* 

\aal_handle_iciptr; 

Evhandle 

\next_packet_aiTival; 

Evhandle 

\call_end_intrpt; 

Distribution* 

\int_arrival_distptr; 

Distribution* 

\call_wait_distptr; 

30 

Distribution* 

\calLduration_disq)tr; 

AmsT_Traf_Contract* 

Vraf_con_ptr; 

AmsT_Neighbor_Data*  \nbr_data_ptr; 

Badd_Sch_Mod_Data 

NScheduler_Module; 

35 

Badd_Channel_Desc* 

NchanneLptr; 

Temporary  Variable  Block _ 


int 

primitive; 

int 

cd_packet_size; 

int 

clark_dest_addr; 

int 

calls_list_size; 

int 

index  =  0; 
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int 

channeLindex; 

int 

sch_channel_mdex; 

int 

check_chan__index; 

int 

call_bit_rate; 

10 

int 

calLcompLchannel ; 

int 

calLrelease_channel; 

int 

total_channeIs  =  0; 

int 

channeLcount=  0; 

int 

value; 

15 

int 

least^calls; 

int 

least_calls_index; 

int 

tenip_intrpt_type; 

int 

temp_intipt_code; 

int* 

intjptr; 

20 

int* 

diannel_size_ptr; 

double 

peaJk_cell_rate; 

double 

cdv_tolerance; 

double 

int_arr_time; 

double 

call_wait_time; 

25 

double 

calLduration; 

double 

event^time; 

double 

channeLcompLtime; 

double 

temp_double; 

double 

temp_PCR; 

30 

double 

time^enqueued; 

double 

time_dequeued; 

double 

time_in_queue; 

extern  int 

total_calls_requested; 

extern  int 

total_calis_generated; 

35 

extern  int 

total__calls_received; 

extern  int 

total_calls_active; 

extern  int 

max_call  s_active; 

char 

string[U]; 

Ici* 

if_iciptr; 

40 

Ici* 

req^iciptr; 

Ici* 

calLiciptr; 

Ici* 

signal_iciptr; 

Ici* 

setup_iciptr; 

Ici* 

upper_handle_iciptr; 

45 

Ici* 

check_channel_i  ciptr. 

Ici* 

channeljciptr; 

Ici* 

sch_channel_iciptr; 

Prohandle 

call_gen_prohandle; 

Prohandle* 

call_gen_proptr; 

50 

Evhandle 

this^event; 

Evhandle 

next_event; 

Evhandle 

scheduler^event; 

List* 

channel_listptr; 

List* 

sch_channel_listptr; 

55 

FILE* 

input_file; 

Compcode 

channel_schedu  led; 

Compcode 

sch_requested; 

AmsT_TraL_Contract*  tmp_traf_con_ptr; 

60 
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Piiiictlbri  Block 


10 


15 


20 


25 


30 


35 


40 


45 


50 


void 

badd_calI_sch_nbr_intrpt_proc  (ndata^ptr,  ndesc_ptr,  state__ptr) 
AinsT_Neighbor_Data*  ndata_ptr; 

AinsT_Neighbor_Desc*  ndesc^tr; 
void*  state_4)tr* 

{ 

AmsT_Neighbor_Verify_Desc  vdesc; 

int  to_sw_s6ream_mdex; 

/**  This  procedure  handles  a  neighbor  notification  event  in  an  AMS 
/**  trafgen  specific  manner.  It  determines  the  neighbors  object 
/**  ID  and  type,  and  verifies  that  there  are  a  correct  number  of 
/**  interconnections. 

FIN  (badd_calLsch_nbr_intipt__proc  (ndata_ptr,  ndesc_ptr,  state_ptr)); 

/*  Switch  based  on  the  AMS  type. 
switch  (ndesc_ptr->moduIe_amstype) 

{ 

caseAMSC.MTYPE  AAL: 

{ 

/*  Build  the  verify  desc  data  structure. 


**/ 

♦*/ 

*♦/ 


*/ 


vdesc.mod_id 
vdesc.nbrjd 
vdesc.nbr_id_ptr 
vdesc  .mod_name 
vdesc.nbr_naine 
vdesc.nbr_type 
vdesc.from_nbr_strm_cnt 
vdesc.froin_nbr_stnn_index_ptr 
vdesc.to_nbr_stnm  cnt 


vdesc.to_nbr_stim_index_ptr 


=  niy_id; 

=  ndesc_ptr->moduIe_objid; 

=  &aal_module_id; 

=  "BADD  Call  Scheduler"; 
=  "AAL"; 

=  AMSC_MTYPE_AAL; 

=  1; 

=  OPC^NIL; 

=  1; 


=  &to_aal_stream_index; 


/*  Verify  that  the  neighbor  has  the  correct 
I*  characteristics. 
ams_neighbor_verify  (&vdesc); 

break; 

) 

case  BADD_MTYPE_SCHEDULER_(XIENT: 

{ 

/*  Build  the  verify  desc  data  structure. 


*/ 

*/ 


vdesc  .mod_id 
vdesc.nbr_id 
vdesc.nbr_id_ptr 
vdesc.mod_name 
vdesc.nbr_naine 
vdesc.nbr_lype 
vdesc.from_nbr_strm_cnt 
vdesc.from_nbr_stnn_index_plr 
vdesc.to_nbr_strni  cnt 


vdesc.to_nbr_stnn_index_ptr 


=  my Jd; 

=  ndesc_ptr->moduIe_objid; 

=  &req_moduIe_id; 

= "BADD  Call  Scheduler"; 

= "call_req“; 

=  BADD_MTYPE_SCHEDIILER^CLIENT; 

=  1; 

=  OPC.NIL; 

=  1; 


=  &to_req_stream_index; 


/*  Verify  that  the  neighbor  has  the  correct 
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55 

/*  characteristics. 

1*  ams_neighbor_veriJy  (&vdesc);  */ 

break; 

) 

*/ 

60 

default: 

1 

/*  This  is  an  unexpected  neighbor  notification. 

♦/ 

/*  Issue  error  message. 

*1 

65 

op_sim_end(" Process  received  a  neighbor  notification 
“of  an  unexpected  type.  Simulation  terminated," 

break; 

} 

) 

from  a  module", 

,  OPC^NIL,  OPC^NIL); 

70 

FOUT; 

} 

75 

void 

badd_calLsch_spurious_signal_handle  () 

{ 

Ici*  if_iciptr; 

Ici*  release_if_iciptr; 

80 

int  primitive; 

Ici*  ILhandle^iciptr; 

Packet*  pkptr. 

/*  This  procedure  handles  spurious  interrupts. 

*/ 

85 

/*  Only  three  types  of  spurious  interrupts  can  be  accepted.  All 

*/ 

/*  others  must  result  in  an  op_sim_end  {),  These  three 

*/ 

/*  interrupts  are: 

*/ 

/*  1.  AnAALESTABInd. 

*/ 

/*  2.  An  AAL  RELEASE  Con. 

*/ 

90 

/*  3.  A  packet  arrival. 

FIN  (badd_call_sch_spurious_signal_handIe  ()); 

if  ( AAL^CALL^SETUP) 

{ 

/*  This  is  a  signal  from  the  AAL. 

*1 

95 

*/ 

/*  Obtain  the  ICI  pointer. 
ifjciptr  =  opJiitrpt_ici  (); 

*/ 

100 

/*  Obtain  the  primitive  from  the  ICI. 
opJci_attr_get  (ifjciptr,  "primit ive “ ,  &primitive); 

*/ 

/*  Obtain  the  *  lower  layer  handle*  from  the  ICI. 

op (if-iciptr,  "  l owe r  layer  hand  1  e " ,  &lLhandle Jciptr); 

*/ 

105 

/*  Switch  on  the  *  primitive* .  */ 

switch  (primitive) 

{ 

caseAMSC  AAL  ESTAB  Ind: 

110 

{ 

/*  This  is  an  ’establish  indication’  from  the  AAL. 

*/ 

if(LTRAC:E„ACTIVE) 
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115 


120 


125 


130 


135 


140 


145 


150 


155 


{ 

®PJJrg_odb_print_major(pid_strmg,  “Received  spurious  AAL  ESTABLISH  Request  signal.", 
“Call  not  accepted. ",  “Sending  AAL  RELEASE  Request  signal. ",  OPC_NIL); 

} 


/*  Set  the  '  upper  layer  handle*  in  the  interface  *! 

f*  ICI  for  the  *  establish  indication*  signal,  since  */ 

/*  the  lower  layer  expects  it  to  be  filled  in.  The  */ 

/*  ICI  is  not  destroyed,  since  this  is  a  forced  *l 

f*  interrupt  and  the  lower  layer  process  expects  */ 

/*  to  obtain  the  handle  from  the  ICI  when  the,  */ 

/*  control  returns:  */ 

opJ^L^ttr^set  (if  Jciptr,  "upper  layer  handle  “,  OPC_NIL); 

/*  Simply  send  an  AAL  RELEASE_Req  to  request  that  */ 

/*  the  connection  be  released.  */ 

release_if_iciptr  =  op  Jci^create  (AMSC_INTERFACE_ICI); 


opJci_attr_set (release^ifjciptr,  “primitive",  AMSC_AAL_RELEASE_Req); 

® (release_if_iciptr,  "  1  owe r  layer  handle", Il_h^dle_iciptr) ; 

®P  (release^iLiciptr); 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  module.  */ 
op Jntrpt_scheduIe_reinote  (op_sim_time  (),  AMSC_INTERFACE_SIGNAL,  aal_moduIeJd); 

break; 

) 

case  AMSC_AAL_„RELEASE_Con: 

{ 

!*  This  is  a  '  release  confirm*  from  the  AAL.  */ 

if(LTRACE^ACTIVE) 

{ 

op_prg_odb_print_major(pid_string,  "Received  spurious  AAL  RELEASE  Confirm  signal.", 
"This  in  response  to  AAL  RELEASE  Request  terminating  spurious  connection.",© 

} 


/*  This  is  a  response  to  our  earlier  *  release  *1 

/*  request*  which  was  a  response  to  the  */ 

/*  spurious  * estab  indication* .  */ 

i*  Do  nothing  other  than  destroy  the  ICI.  *1 

op  Jci_destroy  (if_iciptr); 


break; 

} 
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default: 

{ 

/*  This  is  some  other  completely  unexpected  *f 

!*  signal.  Issue  error  message  and  terminate  *f 

/*  simulation.  */ 

op_siiii_eDd (" In  badd_call_scheduler/  Received  unexpected  signal.","","",""); 

} 

} 

else  if  (op  Jntrpt^type  ()  =  OPCJNTOPT^STRM) 

{ 

/*  This  is  a  spurious  packet  arrival.  The  amsjrafjgen  ♦/ 

f*  just  destroys  this  packet.  *i 
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if  (LTEUCE^ACTIVE) 

{ 

op_prg_odb_print_major (pid_string,  “Received  spurious  DATA  packet. 
"Destroying  the  packet  OPC_NIL); 

} 

/*  Get  the  packet  fromt  the  stream  and  destroy  it,  */ 

pkptr  =  op_pk^et  (op_intrpt_strm  ()); 
op_pk_destroy  (pkptr); 


/*  This  is  some  other  completely  unexpected 
i*  interrupt.  Issue  error  message  and  terminate 
/*  simulation. 

Op_siin__end ("Received  unexpected  interrupt.' 


void 

badd_calLsch Jist_print  (calls Jist) 

List*  calls_list; 

{ 

int  list_size; 
inf  index  =  0; 
int  list_packet_si2e; 
int  list_dest_addr; 
int  list_qos_class; 
int  Iist_AAL_type; 
double  list_bit_rate; 
double  list__inf.arT_tinie; 
double  list_call_wait_time; 
double  list_calLduration; 
double  list_peak_ceILrate; 

Ici*  req_iciptr; 

/*  This  procedure  will  print  all  the  callsjdescs  in  the  calls  jpending  list  *! 
FIN  (badd_calLsch_list_prmt(calIs_list)); 

list_size  =  op_prgJist_si2e(calls_list); 

if  (list_size  =  0) 

{ 

printf(“  Attempting  to  print  empty  call_l ist . \n"); 


for  (index  =  0;  index  <  list_size;  index++) 

{ 

req_iciptr  =  (Ici*)  op_prgJist_access  (callsjist,  index); 
if  (req_iciptr  ~  OPC^NIL) 

badd_calI_sch_eiTor( "Unable  to  get  req_iciptr  from  calis_pending  1  ist . OPC_NIL,  OPC_NIL); 

if  ((op Jci_attrjget  (req_iciptr,  "  i  n  ter  a  rr  i  va  1  t  ime " ,  &Iist_int_arr_tmie)  =  OPC_COMPCODE_FAILURE)  II 
(op Jci_attr_get  (req_iciptr,  "packet  size",  &list_packet_si2e)  =  OPC_COMPCODE_FAILURE)  II 
(opJci_attr^et(reqJciptr,  "call  wait  time",  &Iist_calI_wait_time)  ===  OPC_COMPCODE_FAILURE)  II 
(o p_ici_attr_5et  (req_iciptr,  "call  duration",  &li st_caIl_duration)  ==  QPC  COMPTODE  FATT J TRF)  1 1 
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(opJd_attr jget(req_iciptr,  "dGst  addr“,  &Iist_ciest_addr)  =  OPC_COMPCODE_FAILURE)  II 
(op_ici__attr jget (req_iciptr,  "QoS  class", &list_qos__class)  =  OPC_COMPCODE_FAEURE)  II 
(op  Jci^attr jget  (reqjdptr,  " AAL  type " ,  &Iist_AAL_type)  ==  OPC_COMPCODE_FAILURE)  II 

(op_ici_attrjget  (reqjciptr,  "peak  cell  rate",  &list_peak_ceILrate)==  OPC_COMPCODE_FAILURE)) 
badd_call_sch_error( "Unable  to  get  values  from  call_reg  iciptr",  OPC_NIL,  OPC_NIL); 
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printf("In  badd_call_schGduler. printing  cal ls_pending  list:  int_arr_timG  =  %f.\n", 
list_int_arr_time); 

printf("In  badd_call_scheduler .printing  cal ls_pGnding  list:  packet_si2e  -  %d.\n", 
list_packet_si2e); 

printf("In  badd_call_schedulGr .printing  cal ls_pending  list:  call_wait_time  =  ^f.\n", 
Iist_caILwait_time); 

prmtf("In  badd_call_scheduler.printing  cal ls_pending  list:  call_duration  = 
Iist_calLduration); 

prmtf("In  badd_call_scheduler. printing  cal ls_pending  list:  dest_addr  =  %d.\n", 
Iist_dest„addr); 

printf("In  badd_call_schedulGr  .printing  cal  ls_pending  list:  qos_class  =  %d.\n", 
list_qos_cIass); 

printf("In  badd_call_scheduler. printing  cal ls_pending  list:  AAL_type  =  %d.\n", 
Iist_AAL_type); 

printf("In  badd_call_scheduler. print ing  cal ls_pending  list:  peak_cell_rate  =  %f.\n", 
list_peak_celLrate); 

printf("In  badd_call_scheduler. printing  cal ls_pending  list:  bit_rate  =  %f.\n", 
list_peak_cell_rate  *  424); 

}  /*  End  for  loop  *f 
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FOOT; 

} 

void 

badd_calLsch_error  (msgO,  msgl,  msg2) 
char*  msgO; 

char*  msgl; 

char*  msg2; 

{ 

/**  Print  an  error  message  and  exit  the  simulation,  **/ 
FIN  (badd_calLsch_eiTor  (msgO,  msgl,  msg2)); 


270 


op_sim__end ("Error  in  badd_call_scheduler  process:", 
msgO,  msgl,  msg2); 


FOOT; 

) 


Diadni0^tc  Slock 

/*  Display  connection  information,  if  requested.  *1 
if  (LTRACE^CONNECT_ACTIVE) 

{ 

5  /*  Print  information.  */ 

ams_neighbor_data_print  (nbr_data_ptr,  ams_neighbor_desc_print_noop); 

) 
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exit  execs 
status 


value 

default  value 

INIT 

string 

St 

(See  below.) 

texlllst 

(empty) 
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forced 

toggle 
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enter  execs  IN  IT 


/*  Determine  the  initial  values  of  the  state  variables  and  set  up  */ 

f*  the  initial  state  of  this  instantiation  of  the  ams_traf_gen  *f 

f*  process.  ♦/ 

5  /*  Obtain  the  object  ID  of  this  process*  parent  module.  *1 

my_id  =  op_id_seIf  (); 

/*  Determine  whether  or  not  the  simulation  is  in  debug  mode.  *f 

debug_mode  =  op_sim_debug  (); 

10 

/*  Initialize  the  AAL  module  object  ID  to  NULL  value.  */ 

aal_moduleJd  =  OPC_OBJID_NULL; 
req_module  Jd  =  OPC__OBJID_NULL; 

15  /*  Create  a  list  for  storing  the  calls  as  they  arrive  ♦/ 
calls^pending  =  op_prg_list_create(); 

/*  Read  the  static  channels  input  file  and  create  lists  accordingly.  *1 
static_channels  =  op_prg_list_create(); 

20  caJls^scheduIed  =  op_prgJist_create(); 

/*  Open  the  channel  definition  file.  */ 

if  ((input_file  =  fopen( " /usr/work/benton/ input_channels ",  *' r")) 

=  NULL) 

25  { 

badd_caiLsch_error(" Problem  opening  static  channel  definition  file.", 

OPC^NIL,  OPC_NIL); 

} 

if  (fgets  (  string,  MAXSI2E,  input^file )  !=  NULL) 

30  { 

if  (LTIL\CE_C  ALL_CHANNELS^ACriVE) 
printf("In  badd_call_sch.  init ;  string  is  %s  .  \n",  string); 
if  (get_digit(stiing,  &value)  =  OPC_COMPCODE J^AILURE) 

{ 

35  badd_call_sch__error ("Invalid  number  of  static  channels.", 

OPC_NIL,  OPC.NIL); 

) 

total_channels  =  value; 

if  (LTRACE.C  ALL_CHANNELS_ACTIVE) 

40  { 

printf("In  badd_call_sch.  load_static_channels  function  after  reading  channel"); 
printf(“  count ;  tot al_channels  =  %d.\n",  total  channels); 

} 


45  if(totaI^channels>MAX^CHANNELS) 

{ 
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badd_calI_sch_error( "Requested  virtual  channels  exceeds  maximum  allowed.", 

OPC.NIL,  OPC_NIL); 

} 

while  ((fgets  (  string,  MAXSIZE,  input_file  )  !=  NULL)  && 

(chaimeI_count  <  totaJ_channels)) 

{ 

if  (LTRACE^C  ALL_CHANNELS„ACTIVE) 

( 

printf("In  badd_call_sch. init /  reading  each  channel  size;"); 

printf( "  cha nne  l_c  oun t  =  % d .  \n " ,  channeI_count); 

printf("In  badd_call_sch. init ;  string  value  is  %s.  \n“,  string); 

) 

if  (get_digit(strmg,  &value)  =  OPC.COMPCODE  FAILURE) 

{ 

badd__c^I__sch_erTor (" Invalid  number  for  static  channels.", 

OPC_NIL,  OPC.NIL); 

) 

if  (value  >  8000000) 

{ 

badd_calLsch_eiTor  ( 

} 

channeLptr  =  (Badd_ChaiineI_Desc*)  op_prg_inem_aIloc(sizeof(Badd_Qiaimel_Desc)); 
if  (channeLptr  =  OPC_NIL) 

{ 

badd_caII_sch_error( "Unable  to  allocate  memory  for  channel  definition.  ", 

OPC_NIL,  OPC^NIL); 

) 

channeLptr->ch_capacity  =  value; 
channeLptr->ch_calIs_sch  =  -1; 
channel_ptr->ch_calls_compI  =  0; 
channel_ptr->ch_compl_time  =  0.0; 

op_P*‘gJistJnsert(static_channeIs,  channeLptr,  OPC_LISTPOS_TAIL); 
if  (LTTL\CE_CALL_CHANNELS„  ACTIVE) 

{ 

printf("In  badd_call_sch.  init ,  channel  value  saved  =  %d . \n“,  channeLptr->ch_capacity); 
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/*  Create  a  list  to  store  the  calls  for  this  channel  */ 
channeLlistptr  =  op_prgJisLcreate(); 
if  (channeLlistptr  =  OPC_NIL) 

{ 

b^<l«.calLsch_error( "Unable  to  allocate  memory  for  channel  list.", 
OPC_NIL,  OPC_NIL); 

} 

op_P*'gJistJnsert(caIls_scheduled,  channeLlistptr,  OPC_LISTPOS_TAIL); 
channeLcount  =  channeLcount  +  1; 

) 

if  (LTRACE^CALL_CHANNELS„ACriVE) 

( 

channel_count  =  op_prg_IisLsize(static_channels); 

printf(*In  badd_call_sch.init,  elements  in  static  channels  "); 
printf ( "list  =  %d.\n",  channeLcount); 
channeLcount  =  op_prg_list_size(calls_scheduled); 
printf("In  badd_call_sch.  init  ^  elements  in  sch_channels  "); 
printf( "list  =  %d.\n",  channeLcount); 

} 
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fclose(input_file); 

/*  Open  file  for  storing  call  timer  information.  *J 

if  ((output jfile  =  fopen( "  /usr /work/ bent  on  /  ou t  pu t_ca  1  fo  "w")) 

=  NULL) 

{ 

badd_call_sch_error( " Problem  opening  output_call_times  file.", 

OPC.NIL,  OPC^NIL); 

} 

/*  Write  a  file  format  statement  as  the  first  line  in  the  file.  */ 

^uts("File  Format:  Channel  Enqueued„Time  Dequeued_Time  Time_In_Queue  PCR\n", 
ou^ut_file); 

/*  Open  file  for  storing  calls  completed  information.  */ 

if((output_calls  =  fopen(-/usr/work/benton/output_call_completed_fifo",  "w")) 

=  NULL) 

{ 

badd_calI_sch_error(" Problem  opening  output_call_completed  file.", 

OPC_NIL,  OPC_NIL); 


/*  Write  a  file  format  statement  as  the  first  line  in  the  file.  V 

i|)Uts("File  Format:  Channel  Time_completed  PCR . \n",  output_calls); 

sch_channeLcount  =  op_prgJist_si2e(static_chaimels); 

/*  Generate  PID  display  string.  */ 

sprintf  (pid_string,  "badd_cal l_scheduler  PID  ( %d ) ",  op_pro__id  (op_pro_seIf  ())); 


I*  Obtain  and  send  out  neighbor  information. 

nbr_data_ptr  =  ams_neighbor_data_build  (); 

ams_neighbor_notify  (nbr_data_ptr,  AMSC_MTYPE_AAL_CLIENT); 


if  (LTTIACE.CAIX^SCHEDULER^ACTIVE) 

{  • 

printf("In  badd_call_scheduler.init :  print  neighbor  info.\n"); 
ams_neighbor_data_prmt  (nbr_data_ptr,  ains_neighbor_desc_print_noop); 

} 


/*  This  Scheduler  ^Module  is  attached  to  any  process  spawned  by  *l 
I*  this  baddjcalljrequestor  process.  *1 

I* Scheduler _Module  =  (Badd_Sch_Mod_Data*)  op _prg_mem_alloc(sizeof[Badd_Sch_ModJ)ata));  */ 
op_pr  o_modinem_instalI(&Scheduler_Modu  le) ; 

/*  Initialize  the  model  parameter  attributes.  *f 

op_ima__obj_attr_^et  (myjd,  •  scheduler  delay",  &time_to_next_scheduIer); 
op_ima_ob j_attr jget  (my_id,  "  t  ra  n  smi  s  s  i  on  delay",  &trans_delay) ; 
op Jma_obj_attrjget  (myJd,  "  cha  nne  1  delay",  &charmeLdeIay); 
op_ima_obj_attr jget  (my_id,  "calls  pend  i  ng " ,  &max_calls_pending); 

/*  Initialize  the  endjsimjtime  varaible  */ 

op_i ma  sim  attr  get(OPC_IMA_DOUBLE,  "duration",  &end_sink_time) ; 

/*  printf["end_sim_time  =  %f.\n‘\  endjsimjime);  *! 

if  (LTRACE^CALL_SCHEDULER_ACTIVE) 

{ 

pRntf(“In  badd_cail_scheduler.init  state:  Leaving  init  state.  \n"); 
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/*  Amsjraf_gen  expects  either  a  neighbor  notification  interrupt,  *! 

I*  or  a  spurious  signal.  *{ 

if  (NEIGHBOR_NOTIFY) 

{ 

5  /*  This  is  a  'neighbor  notify'  signal.  *1 

ifCLTRACE.ACTIVE) 

{ 

op_prgu_odb_priDt_major(pid_string,  “Received  neighbor  not  if  ication. ",  OPC^NIL); 
} 

10 

/*  Handle  the  neighbor  notification.  *} 

ams_nejghbor_mtemipt_hand!e  (nbr_data_ptr,  badd  call  sch.nbr  intipUproc,  OPC  NIL); 

} 

else 

15  { 

!*  This  is  a  spurious  interrupt.  Handle  appropriately.  *J 

badd_call_sch_spurious_signaI_hand!e  (); 

} 
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5 

10 

1*  Compare  the  number  of  calls  in  the  calls pending  list.  */ 

/*  If  the  number  exceeds  the  max  calls _pending,  schedule  *1 
/*  a  call  to  execute  the  scheduler.  *1 

nuinber_calls_pending  =  op_prgJist__size(calls__pending); 
if  (number_calls_pending  >  max_caJIs_pendmg) 
op  Jntrpt_schedule_self  (op_sim_ti  me  (),  B  ADD_CALL_SCHEDULER); 

1*  Schedule  the  next  scheduling  event  */ 
if  (number_calls_pending  >  0) 

op  Jntrpt_schedule_self  (op_sim_time  ()  +  time_to_next_scheduIer,  BADD_CALL_SCHEDULER); 

_ 

temp_intrpt_type  =  op  Jntrpt_typeO; 
temp_intipt__code  =  op_intrpt_code(); 

if  (LTRACE^C  ALL.DISP^ACTIVE) 

5  { 

printf("In  badd_call_scheduler. dispatch:  received  SIGNAL. \n“); 

printf("ln  badd_call_scheduler .dispatch :  intrpt_type  =  %d .\n", temp_mtrpt_type); 

printf("In  badd_call_scheduler. dispatch:  intrpt_code  =  %d.\n“,temp_intrpt  code); 

}  /*  Endif(LTRACEj:AULJ)ISP_ACrm}^l 

10 

if  (SIGNAL) 

{ 

signa]_iciptr  =  op  Jntrpt_ici(); 
if  (signaljciptr  =  OPC_NIL) 

15  badd_calLsch_eiTor( "Unable  to  get  signal_iciptr . OPC^NEL,  OPC_NIL); 

if  (LTRACE_CALL_DISP_ACTI  VE) 

{ 

op  ici  print(si^al_iciptr): 
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20  }  /*  Endif(LTRACE_CALL_DISPj[CTIVE)V 
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sch_channel_iciptr  =  op_intrpt__ici(); 

if  ((opjci^attrjget  (sch.chaimeljciptr,  -  channel  number" ,  &sch_chaimeLindex)  =  OPC_COMPCODE_FAILURE)) 
i5^d__calI_sch_error(“ In  start_call:  unable  to  get  values  from  sch_channel  iciptr" 

OPC^NIL,  OPC^NIL); 

/*  Destroy  the  id  to  recover  space.  Garbage  collection.  */ 
opJci_destroy(sch_channeUciptr); 

if  (LTRACE_CALL^SCH^ACTIVE) 

prmtf(-In  call  scheduler .start_call :  sch_channel  index  =  %d.  \n-,  sch_channeLindex); 
sch_channeLlistptr  =  (List*)  op_prg_Iist_access(calls_scheduled,  sch_channeLindex); 
calljciptr  =  (Id*)  op_prgJist_remove(sch_,channelJistptr,  OPC_LISTPOS_HEAD); 


if  (caU^iciptr  =  OPC_NIL) 
badd_calI_sch_error(“In  start  call. 


unable  to  get  call^iciptr  from  cal  ls_list . OPC_NIL,  OPC_NIL); 


if  ((opJci_attrjget  (calLiciptr, 
(op_ici_attr^et  (call_iciptr, 
(op  Jdattrjget  (calljciptr, 
(op  Jci_attrjget  (calLiciptr, 
(op  Jciattr jget  (calljciptr, 
(op  JcLattrjget  (calLiciptr, 
(op Jci_attr_get  (calLiciptr, 
(op Jci_attrjget  (calLiciptr,  “ 
(opJci_attr_get  (calLiciptr,  " 
badd_calLsch_eiTor(  "Unable 


"  interarr iva  1  time " ,  &int_arrjime)  =  OPC_COMPCODE_FAILlJRE)  II 
" packet  size",  &packeLsize)  =  OPC_COMPCODE„FAILURE)  11 
‘call  wait  time",  &calLwaitJime)  =  OPC_COMPCODE_FAILURE)  11 
•call  duration",  &calI_duration)  ==  OPC_COMPCODE_.FAILURE)  II 
■dest  addr",  &desLaddr)  =  OPC_COMPCODE_FAILURE)  II 
■QoS  class ",  &qos_class)  =  OPC_COMPCODE_FAILURE)  II 
'  AAL  type  - ,  &AAL_type)  ==  OPC_COMPCODE_FAILURE)  II 

peak  cell  rate", 4^eak_celLrate)  —  OPC_COMPCODE_FAILURE)  II 
t  ime  queued " ,  &time_enqueued)  ~  OPC_COMPCODE_FAILURE)) 
to  get  values  from  call_req  iciptr",  OPC_NIL,  OPC^NIL); 


if  (LTRACE^CALL^SCHEDULER_ACTIVE) 

{ 

printf("In  badd_call_scheduler .start _ca  11 ;  int_arr_time  =  %f .  \n",  int_arr_time); 
printf("In  badd_call_scheduler.start_call :  packet_size  =  %d. \n", packeLsize); 
printf("In  badd_call_scheduler-start_call :  call_wait_time  =  %f .  \n",  caILwait_time); 
printf("In  badd_call_scheduler. start _call :  call_duration  =  %f .  \n ",  calLduration); 
printf("In  badd_call_scheduler .start_call ;  dest_addr  =  %d.  \n",  desLaddr); 
printf(*In  badd_call_scheduler.start_call :  qos_class  =  %d. \n",  qos_class); 
printf(“In  badd_call_scheduler. start _call :  AAL_type  =  %d.  \n",  AAL_type); 
printf("In  badd_call_scheduler.start_call :  peak_cell_ratG  =  %f . \n", peak_ceILrate); 

)  /*  End  if(LTEACE_CALL_SCHEDULER_ACTIVE)  */ 

if  (opJcLattr_set  (calljciptr,  "channel  assigned ",  sch^channeLindex)  =  OPC_COMPCODE_FAILURE) 
badd_calLsch_error(" Unable  to  set  sch_channel_index  in  call_iciptr ",  OPC_NIL,  OPC_NIL); 


time_dequeued  =  op_simJime(); 
time_in_queue  =  tinie_dequeued  -  time_enqueued; 

/*  Write  queue  times  to  the  call  timer  output  file.  */ 

iprintf(output_file,  "%d  %f  %f  %f  %f\n", sch_channeLindex,  time_enqueued, time_dequeued, 
time_in_queue,  peak_ceILrate); 

/*  Update  program  counter  */ 
totaI_calls_generated  =  totaI_calis_generated  +  1; 
total_calls_active  =  total  calls  active  +  1: 
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if  (totaI_caIIs_active  >  max_calls_active) 
max_calls_active  =  total_calIs_active; 

55 

if  (LTRACE^C  ALL^SCHEDULER^ACnVE) 

{ 

priiitf("In  badc[_call_scheduler,  start;  starting  call  to  dest  %d.\n", 
dest_addr); 

60  }  /♦  if{LTRACE_CALL_SCHEDULER_ACTIVE)  *l 


65 


/*  Spawn  a  child  process  to  generate  the  call  data  *1 

calI_gen_prohandIe  =  op_pro_create(“clark_badd_cal  l_generator",  OPC_NIL); 
if  (op_pro__valid(call_gen_prohandIe)  =  OPC_FALSE) 

{ 

badd_call_sch_eiTor('' Unable  to  create  call  generator  process",  OPC^NIL,  OPC_NIL); 

) 


70 


if  (LITUCE^C  ALL^SCHEDULER_ACnVE) 

{ 

printf("ln  badd_call_scheduler,  start;  invoicing  call  generator. \n"); 
priiitf("In  badd_call_scheduler. start :  call_iciptr  =  %x.  \n ",  call_iciptr); 

printf("In  badd_call__scheduler.start_call ;  ind_aal_module_id  =  %d . \n",  Scheduler_Moduie.md_aal_module_id); 


75 


80 


85 


)  /*  if(LTRACE_CALL_SCHEDULER_ACTIVE)  *! 

if  (LTRACE^C  ALL^TIMER_ACnVE) 

printf("In  badd_call_sch. start  call:  current  time  =  %f . \n",  op_siin_time()); 

/*  When  invoking  the  process,  pass  in  the  call  desc  */ 

if  (op_projnvoke(call_gen_prohandle,  calljciptr)  =  OPC_COMPCODE  FAILURE) 

( 

badd_calLsch_error(" Unable  to  invoice  call  generator  process ",  OPC_NIL,  OPC_NIL); 

} 
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enter  execs  send  data 


signal_iciptr  =  op  Jntrpt Jci(); 


5 


10 


if  (signaLiciptr  =  OPC_NIL) 

badd_caJLsch_error( "Unable  to  get  signal_iciptr . OPC_NE.,  OPC_NIL); 

if(LTRACE^CALL^SCHEDULER  ACTIVE) 

{ 

piintf("In  badd_call_scheduler.send  data:  restarting  call_gen  .  \n "); 
op_ici_print(signal_iciptr); 

)  /*  Endif(LTRACE_CALLJCHEDULER_ACriVE)*f 


if  (op_ici_attrjget(signaJ_idptr,  "upper  layer  handle".  &upper  handle  iciptr^^  =  OPC  CQMPrODF  FATT  JTT?F) 
badd_caU_sch_eiTOr( -Unable  to  get  upper  layer  handle. ",  OPC_NIL,  OPC^NIL); 

if  (0PjcLattr__get(upper3andIeJciptr,  -cal  l_gen_prohandle-,  &caJl_gen_proptr)  =  OPC.COMPCODE.FAILURE) 
badd_calLsch_error( -Unable  to  get  call_gen  prohandle. ",  OPC_NIL,  OPC_NIL); 


if  (LTRACE^C  AII._TIMER_ACTIVE) 

20  printf("In  badd_call_sch.send  data:  current  time  =  %f .  \n“,  op_sim_time()); 

if  (opj)roJnvoke(*caU^en_proptr,  signaljciptr)  =  OPC_COMPCODE_FAILURE) 

{ 

badd_calLsch_error(- Unable  to  restart  call_gen  process ",  OPC^NIL,  OPC^NIL)- 

25  ) 
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if  (signaLiciptr  =  OPC_NIL) 
badd_caILsch_error(  "Unable 


to  get 


signal_iciptr .  OPC^NIL,  OPC_NIL); 


if  (LTRACE^C  ALL_SCHEDULER_ACn  VE) 

5  { 

printf("In  badd_call_scheduler  .call_complete:  restarting  cal l_gen .  \n "); 
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opJci_print(signaI_iciptr); 

10 

)  /*  Bndif(LTRACE_CAIl_SCHEDULER_ACriVE)*l 

totaI_caIls_received  =  total_caUs_received  +  1; 
total_calIs__active  =  totaI_calls_active  - 1; 

15 

if  (op  Jci_attrjget(signal Jciptr,  "upper  layer  handle",  &upper_handlejciptr)  =  OPC_COMPCODE_FAILIIRE) 
badd_calLsch_error( "Unable  to  get  upper  layer  handle OPC_NIL,  OPC^NIL); 

if  (opJci_attr__get(signaJ_idptr,  -traffic  contract ",  &tmp_1raf_con_ptr)  =  OPC_COMPCODE„FAILURE) 
badd_caIl_sch_eiTor( -Unable  to  get  traffic  contract OPC_NIL,  OPC.NIL); 

20 

if  (op Jci_attr jget(signal  Jciptr,  -ba  dd_ca  1  l_gen_channe  l_i  d  - ,  &calLcompI_chaimel)  ==  OPC_COMPCODE_FAILURE) 
badd_caILsch_error(- Unable  to  get  call_gen  prohandle. ",  OPC^NIL,  OPC_NIL); 

25 

/*  Write  completion  time  and  PCR  to  the  calls  completed  output  file.  V 
tenip_PCR  =  tmp_traf_coD_ptr->calling_ctd.src_tr^_desc.pcr; 

^riiitf(ou^ut_caIls, -%d  %f  %f  \n-,  call_compLchanneI,  op_sim_time(),  temp_PCR); 

30 

chaimeLptr  =  (Badd_ChajnneLDesc*)  op_prg_list_access(static_channels,  calLcompLchannel); 
channel_ptr->ch_calls__sch  =  channeLptr->ch_caUs_sch  -  1; 
chaimeI_ptr->ch_calIs_compl  =  channeLptr->ch_caIls_compl  +  1; 

if  (opJci_attrjget(upper_handleJdptr,  -call_gen_prohandle-,  &calI_gen_proptr)  =  OPC_COMPCODE_FAILURE) 
badd_calLsch_error(- Unable  to  get  call_gen  prohandle. OPC_NIL,  OPC_NIL); 

35 

if  (LTRACE.CAlX^TIMER^ACriVE) 

prmtf("In  badd_call_sch.call  complete:  current  time  =  %f . \n", op  sim  time()); 

if  (op  pro  invoke(*calJ_gen_proptr,  signal  iciptr)  =  OPC  COMPCODE  FAILURE) 

{ 

badd_cali_sch_enror( "Unable  to  restart  call  gen  process",  OPC  NIL,  OPC  NIL); 

} 

40 
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if  (signaLiciptr  =  OPC_NIL) 

badd_call_sch_eiTor( "Unable  to  get  signal_iciptr . OPC_NIL,  OPC_NIL); 

5 

if  (LTRACE_C  ALL_SCHEDULER_ACTIVE) 

( 

printf("In  badd_call_scheduler .call_released;  restarting  call__gen.  \n"); 
op  Jci_pr  int  ( signal_iciptr); 

10 

)  /*  Endif(LTRACE_CALL_SCHEDULER_ACTIVE)*l 

if  (op  Jci_attr__get(  signal  Jciptr,  "upper  layer  handle",  &upper_handlejciptr)  =  OPC_COMPCODE_FAILURE) 
badd_calI_sch_error( "Unable  to  get  upper  layer  handle. ",  OPC_NIL,  OPC_NIL); 

15 

if (opJci_attrjget(signalJciptr,  "badd^cal l_gen_channel_id", &calLrelease_channel)  =  OPC_COMPCODE„FAILURE) 
badd_caIl_sch_error( "Unable  to  get  call_gen  call_release_channel . OPC_NIL,  OPC_NIL); 

channeLptr  =  (Badd_ChanneLDesc*)  op_prg_Iist_access(static_channels,  caILreIease_channeI); 
channel_ptr->ch_calls_sch  =  channel_ptr->ch_calJs_sch  - 1; 

20 

if  (opjci_attrjget(upper_handleJciptr,  "cal  l_gen_prohandle ",  &calI^en_proptr)  =  OPC_COMPCODE_FAILURE) 
badd_calLsch_error( "Unable  to  get  call_gen  prohandle. ",  OPC_NIL,  OPC^NIL); 

total_calIs_active  =  total_calls_active  - 1; 

25 

if  (op  pro  invoke(*call_gen_proptr,  signal  iciptr)  =  OPC  COMPCODE  FAILURE) 

{ 

badd_calI_sch_error( "Unable  to  restart  call  gen  process",  OPC  NIL,  OPC  NIL); 

) 
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/*  This  Scheduler _Module  is  attached  to  any  process  spawned  by  */ 
/*  this  badd_call_scheduler  process.  *1 

op_pro_modmem_instaII(&Scheduler_Module); 
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5  /*  Pass  the  neighbor  information  to  all  children  processes,  */ 

Scheduler_Module.md_neighbor_<Jata_ptr  =  nbr_data_ptr, 
Scheduler_ModuIe.md_aal_moduIe_id  =  aal_moduleJd; 
Scheduler_Module.md„to_aaLstream_index  =  to_aal_stream_index; 
Scheduler_Module.md_caUs_pending_ptr  =  calls^pending; 

10  ScheduIer_ModuIe.md_diaiineLdelay  =  chaimel_delay; 
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5 

/*  This  is  a  spurious  interrupt.  Handle  appropriately.  *1 

prmtf("Bad  signal  received  by  badd_call_scheduler  An"); 
badd_calLsch_spurious_signal_handIe  (); 
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!*  Print  Information  during  testing  *! 

prmtf("Calls  currently  active  is  %d.\n", totaJ_calls_active); 
prmtf("Max  calls  active  in  this  run  was  %d . \n“, max_calls_active); 


5 


calls__list_size  =  op_prg_Iist_size(calls_pending); 
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prmtf("Calls  remaining  in  the  calls_pending  list  at  termination  =  %d.\n'',calls_Iist_size); 


10 


prmtf(“Cal Is  remaining  in  the  calis_scheduled  lists  at  termination .  \n"); 
time_dequeued  =  end_sim_tiine; 


for  (channel_mdex  =  0;  chaimeLindex  <  sch_channeLcount;  chaiinel_mdex-i-+) 

{ 

15  channeLptr  =  (Badd_ChanneLDesc*)  op_prg_Iist_access(static_channels,  chaimeLindex); 
calls^UsLsize  =  channel_pt2'->ch_calls_sch; 
calI_compLchanneI  =  channeLptr->ch_calls__compl; 
channeLcompLtime  =  chaimeLptr->ch_compLtime; 

printf("  Channel  %d:  calls  compl  =  %d,  calls  remaining  =  %d,  completion  time  =  %f.\n", 
20  chaimeLindex,  calLcompLchannel,  calls_list_size,  channel^compLtime); 

channeljis^tr  =  (List*)  op_prgJist__access(calls_scheduled,  chaimeLindex); 


for  (sch.channeLindex  =  0;  sch_channel  index  <  calIsJisLsize;  sch  channeLindex-H-) 

{ 

25  calLiciptr  =  (Ici*)  op__prgJisLaccess(channeLlistptr,  sch_channeLindex); 

if  ((opJcLattrjget  (calljciptr,  "time  queued ",  &tiine_enqueued)  ~  OPC_COMPCODE_FAILURE)) 
badd_calLsch_eiTor(" In  End  Sim:  unable  to  get  values  from  call_req  iciptr", 
OPC.NIL,  OPC_NIL); 

30  time_in_queue  =  time_dequeued  -  time_enqueued; 


35 


!* 

/* 


/*  Write  queue  times  to  the  call  timer  output  file.  */ 

fyrintf(ou^ut_fiIe,  "%d  %f  %f  %f\n",  chaimeLindex,  tinie_enqueued,  0.0, 0.0) ; 
fprintfl output  Jile,  ''%d  %f%f%fn'\  channeljndex,  iime_enqueued,  timejdequeued, 
time_injjueue);  *f 


40 


if  (LTRACE.C  ALL_SCH_ACnVE) 

{ 

badd_caILsch_li  sLprint(channeLlistptr) ; 

) 


45 


/*  Close  the  Output  files.  */ 

fcIose(output_file); 

fcIose(outpuLcalls); 


badd_calLsch_eiTor(" Ending  simulation  in  badd_call_scheduler  .End  Sim.  \n",  OPC_NIL,  OPC_NIL); 
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/*  A  callj^equest  arrived  from  the  call_requestor  above,  */ 

/*  Must  capture  the  call_request  information  from  the  */ 

/*  ICI  and  store  the  call  in  the  call  j>ending_list  *! 

5  reqjciptr  =  opjntrpt Jci(); 
if  (req_iciptr  ~  OPC_NIL) 

badd_call_sch__error( "Unable  to  get  call_req  iciptr . OPC_NIL,  OPC_NIL); 

iO  if  ((op_ici_attrjget  (req_iciptr,  "  int erarr i  va  1  t  ime " ,  &mt_arL.time)  ~  OPC_COMPCODE_FAILURE)  II 
(op  Jci_attr_get  (req Jciptr,  "  pa  cket  size",  &packet_size)  =  OPC_COMPCODE_FAILURE)  11 
(op_ici_attrjget  (req_iciptr,  "call  wait  time",  &call_wait_tune)  =  OPC_COMPCODE__FAILURE)  II 
(op jci_attr_get (req^iciptr,  "call  duration", &calLduration)  ==  OPC_COMPCODE_FAILURE)  II 
(op_ici_attrjget  (req_iciptr,  "  de s  t  a  dd  r  “ ,  &dest_addr)  OPC_COMPCODE_FAE^URE)  11 

15  (op__ici_attrjget  (req_iciptr,  "QoS  class",&qos_class)  =  OPC_COMPCODE_FAILURE)  II 

(op__ici_attrjget  (req_iciptr,  "AAL  type" ,  &AAL_type)  =  OPC_COMPCODEJFAILURE)  li 

(op Jci^attrjget  (req_icip1r,  “peak  cell  rate", ^eak^celLrate)  =  OPC_COMPCODE_FAILURE)) 
badd_call_sch_error("In  badd_call_sch.call_req:  unable  to  get  values  from  call_req  iciptr",  OPC_NIL,  0! 

20  /*  Destroy  the  id  to  recover  space,  garbage  collection.  */ 
opjci_destroy(req_iciptr); 

if  (LTRACE_CALL_SCHEDULER_ACnVE) 

{ 

25  printf("In  badd_call_scbeduler.call_request :  int_arr_time  =  %f . \n“,  int_arr_time); 
printf("In  badd_call_scheduler.call_request :  packet_size  =  %d .  \n",  packet_size); 
printf("In  badd_call_scheduler .call_request :  call_wait_t ime  =  % f . \n " ,  call_wait„time); 
printf("In  badd_call_scheduler.call_request ;  call_duration  =  %f .  \n",  calLduration); 
printf("In  badd_call_scheduler.call_reguest :  dest_addr  =  %d.\n",  dest_addr); 

30  printf("In  badd_call_scheduler-call_request :  qos_class  =  %d. \n", qos_class); 
printf("In  badd_call_scheduler.call_request :  AAL_type  =  %d.\n", AAL_type); 
printf("In  badd_call_scheduler.cali_request :  peak_j:ell_rate  =  %f . \n", peak_ceU_rate); 
printf(*In  badd_call_scheduler  .call_request :  req_iciptr  =  %x.  \n",  req_iciptr); 

}  /*  End  if(LTRACEjCAU_SCHEDULER_ACnVE)  */ 

35 

/*  Create  and  set  the  fields  in  the  interface  ICI.  */ 

/♦  —  Using  local  memory  —  */ 

ifjciptr  =  op_ici_create  ( "badd_cal  l_req_if_ici  "); 

40  op_ici_attr_sct  (if_iciptr,  "interarrival  time",  inl_an‘_time); 
op_ici_attr_set  (ifjciptr,  "packet  size",  packet_size); 
op Jci_attr_set  (if Jciptr,  "call  wait  t ime " ,  call_wait Jime); 
op Jci_attr_set (ifjciptr,  "call  duration",  calLduration); 
op JcLattr^set  (if Jciptr,  "dest  addr",  desLaddr); 

45  op Jci_attr_set  (if Jciptr,  "QoS  class",  qos_class); 
op JcLattr_set (if Jciptr,  "AAL  type",  AAL_type); 
op JcLattr_set (if Jciptr,  "peak  cell  rate", peak_celLfate); 

op_prgJistJnsert(calIs_pendmg,  ifjciptr,  OPC_LISTPOS_TAIL); 

50 

total_calls_requested  =  total_caIls_requested  +1; 

/*  Send  an  intrpt  to  start  the  scheduler  if  not  requested. 
sch.requested  =  OPC_COMPCODE_FAILURE; 
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55 


60 


65 


70 


this_event  =  op_ev__current(); 
next_event  =  op_ev_nextJocal(this_event); 
while  (op_ev_va!id(next_event)) 

{ 

if  ((op_ev_type(next_event)  =  OPC_INTRPT_SELF)  && 

(op  ev_code(next_event)  ~  BADD_CALL  SCHEDULER)) 

( 

if  (LTRACE_CALL_SCH„ACnVE) 
printf(" Pound  scheduler  event,  stopping  search.  \n"); 
sch^requested  =  OPC_COMPCODE_SUCCESS; 
break; 

} 

else 

next_event  =  op_ev_Dext Jocal(next_event); 

} 


l*if(schjrequested  ==  OPC_COMPCODE_FAILURE) 


75 


f*  if(LTRACE_CALL_SCHJCTIVE} 

/*  printf{” Sending  for  scheduler  interrupt \n"); 

I*  opJntrpt_schedule_self(op_simjime  ( },  BADD  CALL  SCHEDULER); 
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/*  Disable  the  intrpts  to  make  this  process  atomic.  */ 

op_intrpt_disabIe(OPC_INTRPT_SELF,  BADD_CALL_SCHEDULER,  OPC_FALSE); 

/*  Remove  all  the  other  events  of  this  type  from  the  events  list.  */ 
this_event  =  op_ev_ciirrent(); 
next_event  =  op_ev_next Jocal(this„event); 
while  (op_ev_vaIid(next__event)) 

{ 

if  ((op_ev_type(next_event)  =  OPC_INTRPT_SELF)  && 

(op_ev_code(next_event)  =  BADD_CALL_SCHEDULER)) 
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if  (LTRACE.C  ALL_SCH_ACTIVE) 

printf( " Found  next  sch  event,  deleting  event.\n"); 
scheduler_event  =  next_event; 
next_event  =  op_ev_next_local(scheduler_event); 
op_ev__caDcel(scheduler_event); 

) 

else 

next_event  =  op_ev_next JocaI(next_event); 


/*  Determine  the  number  of  calls  that  must  be  scheduled.  *1 
calls_list_size  =  op_prgJist_si2e(calls_pendmg); 

25  if(LTOACE_CALL_SCH^CTIVE) 

{ 

if  (calls_list_size  =  0) 

printf("In  badd_call_scheduler .call  scheduler,  attempted  to  schedule  empty  list."); 
else 

30  prmtf("In  badd_call_scheduler.call  scheduler,  calls  . list  size  =  %d.  \n",  calls_list_si2e); 

) 


f*  Attempt  to  schedule  each  call  in  the  calls jjending  list.  *1 
for  (index  =  0;  index  <  calls_list__size;  index-H-) 


if  (LTRACE^C  ALL.SCH.ACTIVE) 

{ 

printf("In  badd_call_scheduler  .call  scheduler,  index  =  %d  .\n",  index); 

40  ) 

/*  Get  a  call  description  from  the  calls _pending  list.  *f 

call  Jciptr  =  (Ici*)  op_prgJist_remove(calls_pending,  OPC_LISTPOS_HEAD); 

45  if  (calijciptr  =  OPC^NIL) 

badd_call_sch_error("In  badd_call_scheduler,call  schedule,  unable  to  get  call_iciptr  from  calls_lis 

*f  ((op_ici_attrjgct  (call_iciptr,  " peak  cell  rate " ,  &peak_ceILrate)  ~ OPC_COMPCODE_FAILURE)) 
badd_calI_sch_eiTor("In  badd_sch.call  schedule:  unable  to  get  values  from  call_req  iciptr. ",  OPC__ND 
50 

if  (LTRACE_CALL^SCH_ACTIVE) 

{ 

prinlf("In  badd_call_scheduler .call  schedule;  peak_cell_rate  =  %f.\n",peak  cell  rate); 

}  /*  End  if(LTRACEj:ALLJCHEDULER_ACT!VE)  V 
55 

calLbit_rate  =  peak_celLrate  *  AMSC_ATM_CELL_SIZE; 

channeLscheduled  =  OPC_COMPCODE_FAILURE; 

60  least^calls  =  999999; 
least_ca]ls_mdex  =  -1; 

I*  Find  the  channels  that  can  support  this  call  and  schedule  this  call  on  the  */ 

/•  channel  with  the  least  number  of  calls  currently  scheduled.  *1 

65  for  (channeLindex  =  0;  channeLindex  <  sch_channeLcount;  channeLindex-H-) 

{ 

channel_45tr  =  (Badd_ChanneI_Desc*)  op_prg_list_access(static_channels,  channel_index); 
if  (LTRACE_CALL.SCH_ACTIVE) 
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prmtf(’‘ln  badd_call_scheduler -call  scheduler,  ch_capacity  =  %d .  \n",  channel_ptr->ch_capacity); 
printf("ln  badd_call_scheduler .call  scheduler,  bit  rate  =  %d .  \n",  call_bit_rate)* 

} 

/*  Determine  if  this  channel  can  support  the  call  */ 
if  (calLbit-.rate  <=  channeLptr->ch_capacity) 

{ 

if  (least_calls_index  <  0) 
least_calls_mdex  =  channeLindex; 

!*  Determine  if  this  channel  has  fewer  calls  than  previous  channels.  */ 
if  (channeLptr->ch_calIs_sch  <  Ieast_calls) 

{ 

least_calls_index  =  chaimeLindex; 

.  Ieast_calls  =  channel_ptr->ch_caUs_sch; 

} 

} 


/*  Found  the  channel  that  can  support  the  call  and  has  the  least  calls  scheduled,  */ 
if  (least_calls_index  >=  0) 

{ 

/*  Remember,  the  list  position  count  is  zero  based.  *f 
if  (LTRACE„CALL_SCH_ACTIVE) 

{ 

printf("ln  badd_call_scheduler.call  scheduler,  least  calls  index  =  %d. \n", least_calls_index); 
printf("In  badd_call_scheduler.call  scheduler,  least  calls  =  %d.  \n",  !east_calls); 


/*  Time-stamp  the  request  with  the  current  time. 

"time  queued",  op_sim__time()); 

/*  Put  the  call  at  the  tail  of  the  correct  channel  callsjscheduled  list.  */ 
channeLUs^tr  =  (List*)  op_prgJist_access(caIIs_scheduled,  Ieast_calls_mdex); 
op_prgJistJnsert(chaimeI_listptr,  calljciptr,  OPC_LISTPOS_TAIL); 

/*  If  this  is  the  first  call  on  the  channel,  start  the  channel.  */ 
if  (Ieast_calls  <  0) 

{ 

if  (LTRACE_C  ALL^SCH^ACTIVE) 

{ 

printf("In  badd_call_scheduier-call  scheduler,  calling  start  call  for  channel  %d.\n", least_calls. 
priiitf("In  badd_call_scheduler .call  scheduler,  least  calls  =  %d . \n", least_calls); 

dianneljciptr  =  opJci_create("badd_channel_ici "); 
op_ici_install(channel_iciptr); 

"channel  niomber",  least_calls__index); 
opJntrpt_scheduIe_self  (op_simJime  (),  BADD_CALL_SCH_START); 

} 


/*  Update  the  calls  scheduled  counter  */ 
least_calls  =  Ieast_calls  +  1; 

channeLptr  =  (Badd_Channel_Desc*)  op_prg_list_access(static_channeIs,  least_calls_index); 
channel_ptr->ch_calls_sch  =  least^calls; 

/*  Update  the  channel  completion  timer.  */ 

if  ((op_ici__attr_get  (calljciptr,  -call  duration",  &calI_duration)  =  OPC_COMPCODE_FAILURE)  11 
(0PjcLattr_^et  (calljciptr,  "call  wait  time",  &call_wait_time)  =  OPC_COMPCODE_FAILURE)) 
badd_caILsch„error(-In  badd_sch.call_sch:  unable  to  get  values  from  call_req  iciptr . OPC_NIL,  01 
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f* 


/* 


135 


if  (op_sim  time()  >  channeI_ptr->ch_compLtime) 

{ 

channel _ptr->ch_compljime  =  op_sim_ume()  +  calljduration  +  call_waitjime  +  channel jdelay  *1 
channel_ptr->ch_compl_time  =  op__sim_time()  +  call_duration  +  channel_delay 
+  trans_delay; 

channel _ptr->chj:ompljime  =  op_simjime()  +  call_duration;  *1 

) 

else 

{ 

channel j>tr->chjcompljime  =  channel _pir->ch_compljime  +  calljiuration  +  callj^aitjime  *1 
channeI_ptr->ch_compl__time  =  channel_ptr->ch_compLtime  +  calLduration 
+  channeLdelay  +  trans_delay; 

channel _ptr->chj:ompljime  =  channel _ptr->ch_compljime  +  calljiuration;  *f 


if  (LTRACE.C  ALL^TIMER^ACTIVE) 

145  printf("ln  badd_call_scheduler-call_schedule;  compl_time  =  %f .  \n ",  channel_^tr->ch_compl_time); 

/*  Signal  this  call  was  successfully  scheduled.  *} 
if(LTRACE.CALL_SCH  ACTIVE) 

{ 

150  printf("In  badd_call_scheduler .call  scheduler:  call  scheduled . \n"); 

} 

channeLscheduIed  =  OPC^COMPCODE  SUCCESS; 

} 


155 


} 


160 


if  (channeLscheduIed  ==  OPC  COMPCODE^FAILURE) 

{ 

printf("Call  parameters  exceeds  the  capacity  of  all  channels. \n"); 

} 


/*  Turn  the  interrupts  back  on.  *f 

opJntrpLenable(OPCJNTRPT_SELF,  BADD_CALL_SCHEDULER); 
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req_iciptr  =  op__intrpt Jci(); 
if  (req^iciptr  =  OPC_NIL) 

badd_call_sch_error( "Unable  to  get  call_req  iciptr. ",  OPC_NIL,  OPC_NIL); 

if  ((op__ici_attrjget  (req_iciptr,  "  int era rr i  va  1  t  ime  “ ,  &int_arr_time)  ==  OPC_COMPCODE_FAILURE)  II 
(opJci_attr _get  (req_iciptr,  "packet  size",  &packet_si2e)  =  OPC_COMPCODE_FAILURE)  II 
(op_ici_attr^et (req_iciptT,  "call  wait  time", &calLwait_time)  =  OPC_COMPCODE_FAILURE)  II 
(op  Jci_attrjget  (req^iciptr,  "call  du  rati  on",  &call_duration)  =  OPC_COMPCODE_FAILlIRE)  1 1 
{opJci_attrjget  (reqjciptr,  "dest  addr ",  &dest_addr)  =  OPC_COMPCODE_FAILURE)  II 

(op Jci_attr^et  (reqjciptr,  "QoS  class",  &qos_cIass)  =  OPC_COMPCODE_FAILlIRE)  II 

(op jci_attrjget  (req_iciptr,  - AAL  type " ,  &AAL_type)  =  OPC_COMPCODE_FAILURE)  II 

(op  jci_attrjget  (reqjciptr,  "peak  cell  rate",  &peak_celLrate)  =  OPC_COMPCODE_FAILURE)  1 1 
(op Jci_attrjget  (reqjciptr,  " channe  1  assigned",  &call_release_channel)  =  OPC_COMPCODE_FAlLURE)) 
badd_call_sch_error("In  badd_call_sch. reschedule;  unable  to  get  values  from  call_req  iciptr" 

opJci_destroy(reqJciptr); 

if(LTRACE  CAIX_RESCHEDULER  ACTIVE) 

{ 

printf("In  badd_call_scheduler. reschedule:  int_arr_time  -  % f .  \n " ,  int_aiT Jime); 
printf("In  badd_call_scheduler. reschedule;  packet_si2e  =  %d- \n", packet_size); 
priiitf("In  badd_call_scheduler. reschedule:  call_wait_time  =  %f . \n",  call_waitjime); 
printf("In  badd_call_scheduler.  reschedule;  cal  Induration  =  %f  .  \n ",  calLduration); 
printf("ln  badd_call_scheduler. reschedule;  dest_addr  =  %d ,  \n",  dest_addr); 
printf("In  badd_call_scheduler- reschedule:  qos_class  =  %d  -  \n",  gos^class); 
printf("ln  badd_call_scheduler,  reschedule :  AAL_type  =  %d .  \n",  AAL_type); 
prmtf(“ln  badd_call_scheduler. reschedule;  peak_cell_rate  =  %f . \n", peaknCell_rate); 
printf("In  badd_callnScheduler  .reschedule:  req_iciptr  =  %x.  \n ",  req^iciptr); 

)/*  Endif(LTRACESALLJCHEDULERJiCriVE)*l 

/*  Reduce  the  channel  completion  time  for  this  call,  it  is  added  back  in  when  the  call  */ 

/*  is  rescheduled,  *} 

channeLptr  =  (Badd_Chajnnel_Desc*)  op_prgJist_access(statiCnChannels,  call_release_channel); 
channeLptr-'>ch_complJime  =  channel_ptr->ch_compl  Jime  -  calLduration  -  chanjnel_delay  -  trans_delay; 

/*  Create  and  set  the  fields  in  the  interface  ICI.  *1 

ifniciptr  =  opJcijreate  ( "badd_cal  l_req_i  f_ici  “); 

op Jci_attr_set  (if Jciptr,  "  interarr iva  1  time " ,  intnarrjime); 
op Jci_attr_set  (if Jciptr,  " packet  size",  packet_size); 
op Jci^attr jet  (if Jciptr,  "call  wait  t ime " ,  call_.wait Jime); 
op Jci_attr_set  (if Jciptr,  "call  durat ion",  calLduration); 
op JcLattrjet  (if Jciptr,  "dest  addr",  desLaddr); 
op JcLattr jet  (if Jciptr,  "QoS  class",  qosjlass); 
op Jcijttr jet  (if Jciptr,  "AAL  type ",  AAL^type); 
op  Jci_attr jet  (if Jciptr,  “peak  cell  rate",  peak_cell_rate); 


OPCnNIL, 


op_prgJistJnsert(calIs_pending,  ifjciptr,  OPC_LISTPOSnHEAD); 


f*if(5ch_requesied  ==  OPC_COMPCODEJAlLURE) 

t*  op _  in  irpt_schedule_self  ( op_sim_time  ( ) ,  BADD_CALL_SCHED  ULER ); 
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/*  Get  the  lei  passed  from  the  call_generator  and  determine  what  channel  must  */ 

f*  be  checked  for  additional  calls.  If  the  channel  has  additional  calls  waiting,  *! 

/*  then  send  an  interrupt  to  start  the  next  call.  */ 

check_chamieUciptr  =  opJntrptjci(); 

if  (op__ici_attr^et  (check_channel_iciptr,  "channel  number ",  &check_chan_inclex)  —  OPC_COMPCODE_FAILURE) 
bii<l_calLsch_erTor(" Unable  to  read  check  channel  iciptr. ",  OPC_NIL,  0PC_NIL); 

opJci_destroy(check_channeLiciptr); 

if  (L'mACE_CALL_SCH_ACTIVE) 

prmtf("In  badd_call_scheduler.call  scheduler. check_channel :  channel  =  %d. \n“,  check_dian_index); 

channel_ptr  =  (Badd_ChanneLDesc*)  op__prgJist_access(static_channeIs,  check_chan_index); 

/*  Check  the  channel  for  additional  calls  waiting  and  start  the  next  call  if  available.  *! 
if  (chamieLptr->ch_calls_sch  >=  0) 

{ 

channeLiciptr  =  opJci_create(  "badd_channel_ici  "); 
op_ici_iDstal  I  (channel_iciptr); 

op_ici_attr_set  (channeLiciptr,  "channel  number",  check_chan_mdex); 
op_intrpt_scheduIe_self  (op_sim_time  ()  +  channeLdelay,  BADD__CALL_SCH_START); 

) 

if  AIX_TIMER^ACriVE) 

printf("In  bad d_call_sch. check  channel:  current  time  =  %f  .\n",  op_sim_tinie()); 
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External  File  Set  I 

attribute  ' 

value 

defauft  value 

external  file  set 

badd  functions 

typed  file 

Process  Model  Commentie-  :  :  _ ^ 

General  Process  Description: 

The  badd__call_scheduler  schedules  and  manages  all  static  channel 
assignments  for  the  BADD  network.  This  model  schedules  calls  by  assigning 
new  calls  to  the  channel  based  on  a  greedy  min-min  algorithm. 

)CI  Interfaces: 

badd_calLrecLifJci 
badd_cal  Lge  n  Jf_ici 

Packet  Formats: 

None. 

Statistic  Interfaces: 

None 

Process  Registry: 

Published  Attributes  and  Expected  Attributes:  None 
Restrictions: 

None 


I  Process  Model  Attributes  I 

Attribute  dest  addr  properties  : 
Property 

.  Value  i' 

Default  Value: 

NONE 

Data  Type: 

Integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Specifies  the  destination  of 
the  call. 

Symbol  Map: 

Symbol  Value 

NONE  -1 

Allow  other  values: 

YES 

Attribute  scheduler  delay  properties 
Property 

Value 

Default  Value: 

0.0 
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Data  Type: 

Attribute  Description: 

Auto,  assign  value: 

Units: 

Comments: 

double 

Private 

FALSE 

seconds 

The  maximum  time  in  seconds 
between  scheduler  events. 

[  Attribute  transmission  delay  properties  I 

Property 

Value 

Default  Value: 

0.25 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Attribute  channel  delay  properties 

Propertv 

Value 

Default  Value: 

7.681  E-05 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Units: 

seconds 

Comments: 

The  delay  between  calls  on 
the  same  channel. 

Attribute  calls  pending  properties 

Property 

Value 

Default  Value: 

0 

Data  Type: 

integer 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

The  maximum  number  of  calls 
to  store  in  the 
calIsjDending  list  before 

• 

running  a  schedule  process.  • 

Process  Modef  Interface  Attributes 

Attribute  begsim  intrpt  properties 

Property 

Value  ■■  ■  ■  '■■ 

Inherit 

Assign  Status: 

Initial  Value: 

hidden 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  a  ’begin  simulation 
interrupt’  is  generated  for  a  processor  module’s  root 
process  at  the  start  of  the  simulation. 
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Symbol  Map: 

NONE 

YES 

Attribute  endsim  Intrpt  properties  . 
Property 

Value 

trtherU 

Assign  Status: 

hidden 

Initial  Value: 

enabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  an  ’end  simulation 
interrupt’  is  generated  for  a  processor  module’s  root 

process  at  the  end  of  the  simulation. 

Symbol  Map: 

NONE 

YES 

Attribute  failure  intrpts  properties 
ProoertY 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments:  ’ 

This  attribute  specifies  whether  failure  interrupts 

YES 

are  generated  for  a  processor  module’s  root  process 
upon  failure  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  intrpt  interval  properties 
Property 

Value 

Inherit  \ 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle  double 

N/A 

Attribute  Description: 

Private 

N/A 

Units: 

sec. 

YES 

Comments: 

YES 

This  attribute  specifies  how  often  regular  interrupts 
are  scheduled  for  the  root  process  of  a  processor  module. 

Symbol  Map: 

NONE 

YES 

Attribute  priority  properties  .  . 
Property 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

0 

N/A 

Default  Value: 

0 

YES 

Data  Type: 

integer 

N/A 

Attribute  Description: 

Private 

N/A 

Low  Range: 

-32767  inclusive 

YES 

High  Range: 

32767  inclusive 

YES 

230 


Process  Model  Repoil:  baddjx^tLschedul^  =  ^ 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 
of  events  that  are  scheduled  to  occur  at  the  same 

simulation  time. 

Symbol  Map: 

NONE 

YES 

Attribute  recovery  intipts  properties 
Property  • 

Value 

Inherit 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

enumerated 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  specifies  whether  recovery  interrupts 
are  scheduled  for  the  processor  module’s  root  process 
upon  recovery  of  nodes  or  links  in  the  network  model. 

Symbol  Map: 

NONE 

YES 

Attribute  super  priority  fM'operties 
Property 

'  Valite " 

■X  •  '  -.-H’ f  Inherit  ' 

Assign  Status: 

hidden 

Initial  Value: 

disabled 

N/A 

Default  Value: 

disabled 

YES 

Data  Type: 

toggle 

N/A 

Attribute  Description: 

Private 

N/A 

Comments: 

YES 

This  attribute  is  used  to  determine  the  execution  order 
of  events  that  are  scheduled  to  occur  at  the  same 

simulation  time. 

!  Symbol  Map: 

NONE 

YES 

Process  Model  Simufation  Attributes 

Attribute  class_AjCDV_tolerance  properties 

Property 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 
variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  A  cells 
may  experience. 

Attribute  class_B  CDV  tolerance  properties 

Property 

Value 

Default  Value: 

0.0 
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Data  Type: 

Attribute  Description: 

Auto,  assign  value: 
Comments: 

double 

Private 

FALSE 

Upper  bound  on  cell  delay 
variance  that  two 
consecutive  Quality  of 

Service  (QoS)  class  B  cells 
may  experience. 

1  Attribute  class_C_CDV_talerance  properties 

Propertv 

Value 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Cortiments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  C  cells 

may  experience. 

Attribute  class_D_CDV_taIerance  properties 

Propertv  .  . 

Value  "... 

Default  Value: 

0.0 

Data  Type: 

double 

Attribute  Description: 

Private 

Auto,  assign  value: 

FALSE 

Comments: 

Upper  bound  on  cell  delay 

variance  that  two 

consecutive  Quality  of 

Service  (QoS)  class  D  cells 

may  experience. 

Header  Biock  _ *  _ 

#iDClude  "  /usr/local  /mi  1 3_di r/3 . 0 . A_DL5/modGls/std/at:m/ams_interfaces . h " 
#include  “  /usr/local /mil 3_dir/3 . 0  - A_DL5 /model s/st d/a tm/ams_aal_inter faces . h“ 
#iDclude  " /usr/worIc/benton/op_codG/badd_interf ace .h" 

5  I*  These  are  transition  conditions.  */ 

((opjntrptjype  ()  =  OPC_INTRPT_REMOTE)  &&  \ 

(op  Jntrpt^code  ()  =  AMSC^INTERFACE_SIGNAL)) 

((opjntrptjype  ()  =  OPCJNTRPT.REMOTE)  &&  \ 

(opJntrpt_code  ()  =.  BADD_REQUEST_SIGNAL)) 

((SIGNAL)  &&  \ 

((primitive  ==  AMSC_AAL_ESTAB_Req)  II  \ 

(primitive  =  AMSC_AA_ESTAB^Ind))) 

((op  Jntrpt Jype  ()  =  OPCJNTRPT^REMO'm)  &&  \ 
(op  intrpt  code  ()  =  AMSC_SAAL_SIGNAL)) 


10 


15 


#define  SIGNAL 


#define  CALL_REQ_SIGNAL 


#define  AAL.CALL^SETUP 


#define  SAAL^SIGNAL 
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(op  JntrptJype  ()  =  OPC^INTRPT^STRM) 

(SIGNAL  &&  (primitive  =  AMSC_AAL_ESTAB_Con)) 

#define  REL^IND  (SIGNAL  &&  (primitive  =  AMSC_AAL_RELEASE_Ind)) 

25  #define  REL.CON  (SIGNAL  &&  (primitive  ==  AMSC.AAL^RELEASE^Con)) 

#define  CALL_START  ((op  JntrptJype  ()  ==  OPCJNTRPT^SELF)  &&  \ 

(op  Jntrpt jode  ()  =  B  ADD^CALL^SCH_START)) 

30  #denne  CALL.END  ((op  intrpt  type  ()  =  OPCJNTRPT^SELF)  &&  \ 

(op  Jntrpt jode  ()  ==  AMSC^TGEN_CALL_END)) 

((op  JntrptJype  ()  =  OPCJNTRPT.SELF)  &&  \ 

(op  Jntrpt__code  ()  ==  BADD.CALL.SCHEDULER)) 

((op  Jntrpt Jype  ()  =  OPCJNTRPT.REMOTE)  &&  \ 

(op  Jntrpt_code  ()  =  BADD.CALL^RESCHEDULE)) 

#define  CHECK„CHANNEL_SIGNAL  ((op JntrptJype  ()  ==  OPC_INTRPT_REMOTE)  &&  \ 

40  (op  Jntrpt__code  ()  =  BADD.CHECK^CHANNEL)) 

#define  WAIT_CALL_DURATION  ((op  Jntrpt  Jype  ()  =  OPCJNTRPT.SELF)  &&  \ 

(op  Jntrpt_code  ()  =  AMSC_TGEN_WAIT_CALL„DURATION)) 

45  #define  END^SIMULATION  ((op Jntrpt  Jype  ()  =  OPC JNTRPT_ENDSIM)) 

#define  NEIGHBOR_NOTIFY  ((op Jntrpt  Jype  ()  =  OPCJNTRPT_REMOTE)  &&  \ 

(op  Jntrpt_code  ()  =  AMSC_NEIGHBOR^NOTIFY)) 

50  #define  NOTIFY_COMPLETE  (ams_neighbor_notifyJs_comp!ete  (nbr_data_ptr)  ~  OPCJIRUE) 

/*  These  are  self  interrupt  codes.  *1 
#define  BADD^CALL^SCH^START  0 

#defioe  AMSC^TGEN_CALL_END  1 

55  #define  AMSC_TGEN_DATA_GEN  2 

#denne  AMSC.TGEN.WATr^CALL^DURATION  3 
#define  BADD^CALL.SCHEDULER  4 

#define  BADD.C  ALLURES  CHEDULE  5 

#define  BADD_CHECK_CHANNEL  6 

60 

These  are  constants  */ 

#defme  MAX.CHANNELS  1024 

#define  MAXSIZE  11 

#derine  MAX.COMPL^TIME  9999999,9 

65 

/*  The  scheduler  process  will  output  trace  information  if  these  conditional  are  true.  *} 

#derine  LTRACE^ACTIVE  (debug_mode  && 

(op_prg  jdbjtrace ^active  ( "  ams ")  (1 
op_P*'g_odbJtrace_active  ( "  ams_t  ra  f " )  II 

70  op_prg_odb_ltrace_active  ( "  ains_t  ra  f_gen " ))) 

#derine  LTR  A  CE_CONNECT_ ACTIVE  (op_prg_odb  Jtracejctive  (  "connect*)) 

#derine  LTRACE_CALL_SCHEDULER_ACnVE  (op_prg_odb  Urace_active  ("call_scheduler")) 
75 

#derine  LTRACE_CALL_SCH_ACnVE  (op_prg_odbjtrace_active  (  "cal  l_sch")) 


\ 

\ 

\ 


#denne  SCHEDULER 
35 

#define  RESCHEDULE 
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#defiDe  LTRACE_CALL_DISP__ACTrVE  (op_prg_odb_ltrace_active  ("cal  l_d  i  sp " )) 

80  #defiDe  LTRACE__CALL_CHANNELS_ACTIVE  (op_prg_odb_!trace_active  (  "call_channels")) 

#denne  LTR ACE_CALL_TIMER„ACTI VE  (op  prg  odb  itr ace  active  ("cal  l_t  imer  “ )) 

#denne  LTRACE_CALL_GREEDY_ACTIVE  (op_prg_odb__ltrace_active  (  "cal  l_greedy“)) 

85 

#deflne  LTRACE_CALLJlESCHEDULER_ACrnVE  (op__prg_odb_Itrace_active  (  "call_rescheduler")) 


90 


/*  Function  declarations.  */ 

void  badd_caILsch_^nbr_intrpt_proc  (); 

void  badd_calI_sch_spurious_signal_handle  (); 

void  badd__call_schjist_print  (); 

void  badd_call_sch_maliix_prixit  (); 

void  badd_caJl_sch_error  (); 


1  State  Variable  Block  1 

int 

\debug_mode; 

int 

\packet_size; 

int 

\dest_addr; 

int 

\AAL_type; 

5 

int 

\qos_class; 

int 

Mo_aal_streain_index; 

int 

\to_req_stream_index; 

int 

\sch_channel_count; 

int 

\number_calls_pending; 

10 

int 

Nniax_calls_pending; 

double 

\avg_rate; 

double 

\channel_delay; 

double 

\trans_delay; 

double 

Ntime_to_next_schedu  I  er; 

15 

double 

Nend_sim_time; 

char 

Npid^string  [128]; 

Objid 

Vnyjd; 

Objid 

\aal_moduIe_id; 

Objid 

\req_module_id; 

20 

List* 

\calls_pending; 

List* 

\calJs_scheduIed; 

List* 

\static_channels; 

FILE* 

V)utput_file; 

FILE* 

\output_calls; 

25 

Id* 

\aal_handle_idptr; 

Evhandle 

\next_packet_aiTivaJ; 

Evhandle 

'^Lend_intrpt; 

Distribution* 

\int_airival_distptr; 

Distribution* 

\calLwait_dis^tr; 

30 

Distribution* 

\calLduration_distptr, 

AmsT_Traf_Conlract* 

\traf_con_ptr; 

AmsT_Neighbor_Data*  \nbr_data„ptr, 

Badd_Sch_Mod_Data 

\ScheduIer_Modu  le; 

Badd_ChanneLDesc* 

\channel_ptr; 

35 
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l  l^emDorarv  Variable  Block  I 

int 

primitive; 

int 

cd_paclcet_size; 

int 

clark_dest_addr; 

int 

calls_list_size; 

5 

int 

index  =  0; 

int 

channel_index; 

int 

sch_channel_index; 

int 

check_chan_index; 

int 

calLbit_rate; 

10 

int 

calLcompLchannel; 

int 

calLrelease„channeI; 

int 

totaI_channels  =  0; 

int 

channeLcount=  0; 

int 

value; 

15 

int 

least_channeLindex; 

int 

ieast_call_index; 

int 

temp_mtipt_type; 

int 

temp_mtrpt_code; 

int 

remain_to_scheduIe; 

20 

int 

row_index; 

int 

coLindex; 

int* 

ink_ptr; 

int* 

channel_si2e_ptr; 

double 

peak_celLrate; 

25 

double 

cdv_toIerance; 

double 

int_arr_time; 

double 

call_wait_tinie; 

double 

call_duration; 

double 

event_time; 

30 

double 

least_compLtime; 

double 

channel_compl_tiine; 

double 

temp_double; 

double 

temp_PCR; 

double 

time_enqueued; 

35 

double 

time_dequeued; 

double 

time_in_queue; 

double* 

compLtime_ptr, 

extern  int 

total_call  s_requested; 

extern  int 

total_calls__generated; 

40 

extern  int 

tota]_caIls_received; 

extern  int 

total_calls_active; 

extern  int 

max_calls_active; 

char 

stringlll]; 

Ici* 

ifjciptr; 

45 

Ici* 

req^iciptr. 

Ici* 

calLiciptr; 

Ici* 

signaljciptr; 

Ici* 

setup_iciptr; 

Ici* 

upper_handlejciptr; 

50 

Ici* 

check^channeljciptr. 

Ici* 

channeLiciptr; 

Ici* 

sch_channel_iciptr; 

Prohandle 

call_gen_prohandle; 

Prohandle* 

call_gen_proptr. 

55 

Evhandle 

this__event; 

Evhandle 

next_event; 

Evhandle 

scheduler_event; 
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List* 

channeljistplr; 

List* 

sch_channeLlistptr; 

60 

List* 

temp_calis_sch_Iist; 

List* 

row^listptr. 

FILE* 

input_file; 

Compcode 

channeLscheduled; 

Compcode 

sch_requested; 

65 

AmsT_Traf_Contract* 

tmp_1raf_con_ptr; 

I  nunction  Block 

void 

badd_call_sch_nbr_intrpt_proc  (ndata__ptr,  ndesc_ptr,  state_ptr) 
AmsT_Neighbor_Data*  ndata__ptr; 

AmsT_Neighbor_Desc*  ndesc_ptn 

5 

void*  state  ptr; 

{ 

AmsT_Neighbor_Verify_Desc  vdesc; 

int  to_sw_stream_index; 

10 

/**  This  procedure  handles  a  neighbor  notification  event  in  an  AMS 

**l 

/**  trafgen  specific  manner.  It  determines  the  neighbor’s  object 

**j 

/**  ID  and  type,  and  verifies  that  there  are  a  correct  number  of 

**/ 

/**  interconnections. 

**f 

15 

FIN  (badd_caILsch_nbr_intipt_proc  (ndata_ptr,  ndesc_ptr,  state_ptr)); 

/*  Switch  based  on  the  AMS  type. 
switch  {ndesc_ptr“>moduIe  amstype) 

{ 

case  AMSC  MTYPE  AAL: 

*1 

20 

{ 

/*  Build  the  verify  desc  data  structure. 
vdesc.mod_id  =  my_id; 

vdesc.nbrjd  =  ndesc_ptr->module_objid; 

vdesc.nbrjd_ptr  =  &aaI_moduleJd; 

*/ 

25 

vdesc.mod_nanie  =  "BADD  call  Scheduler"; 

vdesc.nbr_name  =  "AAL"; 

vdesc.nbr_type  =  AMSC_MTYPE_AAL; 

vdesc.from__nbr_strm_cnt  =  1; 

vdesc.firom_nbr_strm_mdex_ptr  =  OPC^NIL; 

30 

vdesc4o_nbr_stmi_cnt  =  1; 

vdesc.to_nbr_strm_mdex_ptr  =  &to_aal_stream_index; 

/*  Verify  that  the  neighbor  has  the  correct 

*/ 

/*  characteristics. 

*/ 

35 

ams_neighbor_verify  (&vdesc); 

break; 

} 

40 

case  BADD.MTYPE  SCHEDULER  CLIENT: 

( 

/*  Build  the  verify  desc  data  structure. 

vdesc.mod_id  =  my_id; 

vdesc.nbrjd  =  ndesc_ptr->module_objid; 

*/ 

45 

vdesc.nbrjd_ptr  =  &req_module_id;  • 

vdesc.mod_nanie  =  "BADD  Call  Scheduler"; 
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vdesc.nbr_name  =  “call_req"; 

vdesc.nbr_type  =  BADD^MTYPE_SCHEDULER_CLIENT; 

vdesc.from_nbr_stnn„cnt  =  1; 

50 

vdesc.from_nbr_strm_mdex_ptr  =  OPC_NIL; 

vdesc.to_nbr_stmi_cnt  =  1; 

vdesc.to_nbr_stnn_index_ptr  .  =  &to_req_stream_mdex; 

!*  Verify  that  the  neighbor  has  the  correct 

*/ 

55 

1*  characteristics. 

/*  ams_neighbor_veriJy  ( &vdesc};  */ 

break; 

) 

*/ 

60 

*/ 

default 

{ 

/*  This  is  an  unexpected  neighbor  notification. 

1*  Issue  error  message. 

*/ 

65 

op__sim_end ("Process  received  a  neighbor  notification 

from  a  module". 

"of  an  unexpected  type.  Simulation  terminated OPC^NIL,  OPC^NIL); 

break; 

} 

) 

70 

FOUT; 

) 

75 

void 

badd  calLsch  spurious_signal  handle  () 

( 

Id*  if_iciptr; 

Ici*  release_if_idptr; 

80 

int  primitive; 

Ici*  ILhandleJdptr, 

Packet*  pkptr. 

/*  This  procedure  handles  spurious  interrupts. 

*/  . 

85 

/♦  Only  three  types  of  spurious  interrupts  can  be  accepted.  All 

*/ 

/*  others  must  result  in  an  op_simjend  { ).  These  three 

*/ 

/*  interrupts  are: 

*/ 

/*  L  AnAALESTABInd. 

*/ 

/*  2.  An  AAL  RELEASE  Con. 

*/ 

90 

/*  3.  A  packet  arrival. 

FIN  (badd_call_sch_spurious_signal_haiidle  ()); 

if  ( AAL_CALL^SETUP) 

{ 

/*  This  is  a  signal  from  the  AAL. 

*/ 

95 

*/ 

/*  Obtain  the  ICI  pointer. 
if_iciptr  =  op JntrpMci  (); 

♦/ 

100 

/*  Obtain  the  primitive  from  the  ICI. 
op_ici_attr_get  (if  Jciptr,  "primitive",  &primitive); 

*/ 

/*  Obtain  the  'lower  layer  handle'  from  the  ICI. 

op jci_attrjget  (if Jciptr,  " lower  1  ayer  hand  1  e " ,  &lLhandleJciptr); 

*/ 

105 
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115 


120 


125 


130 


135 


140 


145 


150 


155 


160 


/*  Switch  on  the  'primitive' .  */ 

switch  (primitive) 

{ 

case  AMSC„AAL^ESTAB_Ind: 

{ 

/*  This  is  an  'establish  indication'  from  the  AAL,  *1 

if(LTRACE_ACnVE) 

{ 

op_prg_odb_pnnt__major (pid_string,  “Received  spurious  AAL  ESTABLISH  Request  signal.", 
"Call  not  accepted "Sending  AAL  RELEASE  Request  signal OPC_NIL); 

} 


/*  Set  the  'upper  layer  handle'  in  the  interface  */ 

/*  ICl  for  the  'establish  indication'  signal,  since  */ 

/*  the  lower  layer  expects  it  to  be  filled  in.  The  *1 

/*  ICI  is  not  destroyed,  since  this  is  a  forced  *f 

I*  interrupt  and  the  lower  layer  process  expects  */ 

/*  to  obtain  the  handle  from  the  ICI  when  the  *1 

/*  control  returns.  */ 

op_ici_attr_set (if_iciptr,  " uppe r  layer  handle",  OPC_NIL); 

/*  Simply  send  an  AALJlELEASE_Req  to  request  that  */ 

/*  the  connection  be  released.  */ 

release_if_iciptr  -  op__ici_create  (AMSC_INTERFACEJCI); 


op Jci_attr_set  (release_if_iciptr,  "primitive",  AMSC_AAL_RELEASE_Req); 
op Jci_attr_set  (release_if_iciptr,  "  1  ower  1  ayer  hand  1  e " ,  lLhandle_iciptr); 
op_iciJnstan  (release_if_iciptr); 

/*  Send  a  remote  interrupt  which  will  carry  the  ICI  to  the  AAL  module.  *! 
op_intrpt_schedule_remote  (op  sim  time  (),  AMSC_INTERFACE_SIGNAL,  aal_module_id); 

break; 

) 

case  AMSC_AAL_RELEASE_Con: 

{ 

/*  This  is  a ' release  confirm'  from  the  AAL.  */ 

if(LTRACE^ACTIVE) 

{ 

op_prg_odb_print_major  (pid_string,  "Received  spurious  AAL  RELEASE  Confirm  signal.", 
"This  in  response  to  AAL  RELEASE  Request  terminating  spurious  connection.", 
OPC__NIL); 

} 


/*  This  is  a  response  to  our  earlier '  release  */ 

/*  request'  which  was  a  response  to  the  */ 

t*  spurious  '  estab  indication' .  */ 

/*  Do  nothing  other  than  destroy  the  ICI.  V 

op_ici_destroy  (if_iciptr); 


break; 

} 

default: 

{ 

/*  This  is  some  other  completely  unexpected  */ 

/*  signal.  Issue  error  message  and  terminate  *l 


238 


165 


170 


175 


i*  simulation.  */ 

op_sim_end (" In  badd_call_scheduler/  Received  unexpected  signal.","","",""); 
) 

} 

) 

else  if  (op  Jntrpt_type  ()  =  OPC_INTRPT_STRM) 

{ 

/*  This  is  a  spurious  packet  arrival.  The  amsjraf_gen  *1 

/*  just  destroys  this  packet.  *1 

if(LTRACE_ACnVE) 

{ 

op_prg_odb_print_major (pid_string,  "Received  spurious  DATA  packet,", 

"Destroying  the  packet OPC_NIL); 

} 


180 


185 


190 


/*  Get  the  packet  fromt  the  stream  and  destroy  it. 
pkptr  =  op_pk^et  (op Jntrpt_strm  0); 
op_pk_destroy  (pkptr); 

} 

{ 

/*  This  is  some  other  completely  unexpected 
/*  interrupt.  Issue  error  message  and  terminate 
/*  simulation. 

Op_siin_eDd ("Received  unexpected  interrupt 

) 


FOUT; 

} 


195 


void 

badd_calLsch_Ust_prmt  (calls_Ust) 
List*  calls_list; 


200 


205 


210 


int  list_size; 
int  index  =  0; 
int  list_packet_size; 
int  list_dest_addr; 
int  list_qos_class; 
int  list_AAL_type; 
double  Iist_bit__rate; 
double  list_int_arr_time; 
double  list_calLwait_time; 
double  Iist_calLduration; 
double  list_peak_cell_rate; 
Ici*  reqjciptr; 


*/ 


*/ 

*/ 

*/ 

); 


/*  This  procedure  will  print  all  the  calls_descs  in  the  calls _pending  list  */ 
FIN  (badd_call_sch_list_print(calls_list)); 


215  list_size  =  op_prgJist_size(calls_list); 

if  (Iist_size  =  0) 

{ 

printf("  Attempting  to  print  empty  call_list . \n“); 

220  ) 


for  (index  ==  0;  index  <  Iist_size;  index++) 

( 
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req_iciptr  =  (Id*)  op_prgJist_access  (calls Jist,  index); 
if  (req Jciptr  =  OPC_NIL) 

badd_cdLsch_eiTor(" Unable  to  get  req_iciptr  from  calls_pending  list . OPC_NIL,  OPC_NIL); 


i^ ((op_ici_attr_get  (req_idptr,  "  interarrival  t ime ",  &Iist_int__arr_time)  ==  OPC_COMPCODE_FAILURE)  II 
230  (opJci_attr jget  (req__iciptr,  " packet  size",  &list_packet_size)  ==  OPC_COMPCODE_FAILlIRE)  II 

(op_ici_attrjget  (req_idptr,  "cal  1  wait  time",  &list_call_wait_time)  =  OPC_COMPCODE_FAILURE)  II 
(op_ici_attr jget  (req_idptr,  "call  dura  t  i  on " ,  &list_call_duration)  =  OPC_COMPCODE_FAILURE)  I! 
(op Jci_attr_get  (req Jdptr,  -dest  addr",  &Iist_dest_addlr)  ==  OPC_COMPCODE_FAILURE)  II 

(op Jci_attr jget  (req Jciptr,  "QoS  class",  &list_qos_class)  =  OPC_COMPCODE_FAILURE)  I! 

235  (opJci_attr^et  (req Jciptr,  - aal  type " ,  &list_AAL_type)  =  OPC_COMPCODE_FAILURE)  II 

(op Jci_attr_get  (req Jciptr,  "peak  cell  rate",  &list_peak_ceU_rate)  ==  OPC_COMPCODE_.FAILURE)) 
badd_call_sch_error(" Unable  to  get  values  from  call_req  iciptr",  OPC_NIL,  OPC_NIL); 


240 


245 


250 


255 


printf("In  badd_ca ll_scheduler. print ing  cal ls„pending  list:  int_arr_time  =  %f.\n", 
list_mt_aiTjime); 

prmtf(“In  badd_call_scheduler. print ing  calls_pending  list:  packet_size  =  %d.\n", 
Iist_packet_size); 

printf("In  badd_call_scheduler .print ing  calls_pending  list:  call_wait_time  =  %f.\n", 
list^calLwaitJime); 

printf("In  badd_call_scheduler .printing  calls_pending  list:  call_duration  =  %f.\n", 
Iist_call_duration); 

printf("In  badd_call_scheduler .printing  cal ls_pending  list:  dest_addr  =  %d.\n", 
list_dest.addr); 

printf("In  badd_call_scheduler.  print  ing  cans_pending  list:  qos_class  =  %d.\n", 
list_qos_cIass); 

printf("In  badd_call_scheduler.  print  ing  calls_pending  list:  AAL_type  -  %d.\n“, 
list_AAL_type); 

printf("In  badd_call_scheduler .print ing  cal ls_pending  list:  peak_cel l_rate  =  %f.\n", 
Iist_peak_ceII_rate); 

printf("In  badd_call_scheduler.  print  ing  calls_pending  list:  bit_rate  =  %f.\n", 
iist_peak_cell_rate  *  424); 

}  /*  End  for  loop  */ 


260 


FOUT; 

} 


void 

badd_call_sch__matrix_print  (sch_matrix) 
List*  sch_matrix; 

265  { 

int  number_of_rows; 
int  number_of_cols; 
int  list_row_index; 
int  Iist_coI_index; 

270  List*  inatrix_row_ptr, 
double*  list_compl_tinie; 


275 


280 


/*  This  procedure  will  print  all  the  elements  in  the  call  scheduling  matrix  */ 
FIN  (badd_caU_sch_matrix_print(sch_matrix)); 

nuniber_of_rows  =  op_prgJist_size(sch_matrix); 

if  (number_of_row$  =  0) 

{ 

printf("  Attempting  to  print  empty  sch_matrix.  \n"); 

) 
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for  (list_row_index  =  0;  list_row_index  <  number_of_rows;  list  row  index-H*) 

{ 

285  matrix_row4)tr  =  (List*)  op_prgJist_access  (sch_matrix,  list_fow_index); 

if  (matrix_row_ptr  =  OPC_NIL) 

badd_call_scli_error( "Unable  to  get  row  from  sch_matrix. ",  OPC_NIL,  OPC_NIL); 

290  number_of_cols  =  op_prg_Iist_size(matrix_row_ptr); 

if  (number_of_cols  =  0) 

{ 

printf("  Attempting  to  print  empty  row  from  sch_matrix. \n"); 


for  (list_coLindex  =  0;  list_col_index  <  number„of_cols;  Iist_col_index-H-) 


list_compl_time  =  (double*)  op_prg_list__access  (inatrix_row_ptr,  list_col_index); 

printf("In  badd_call_scheduler. printing  sch_matrix  elements:  row  %d,  col  %d,  compl_time  %f.\n" 
Iist_row_index,  list_coLindex,  *Iist_compLtime); 

}  /*  End  for  (list _col_index  =  0;  Ust_colJndex  <  number _of_cols;  list_col_index++)  */ 

}  /*  Endfor(listjrowJndex  =  0;  list_row_index  <  number _of_rows;  listjrowJndex+‘¥)  *1 


badd_call_sch„error  (msgO,  msgl,  msg2) 
char*  msgO; 

char*  msgl; 

315  char*  msg2; 

{ 

/**  Prim  an  error  message  and  exit  the  simulation.  **/ 

FIN  (badd_call_sch_eiTor  (msgO,  msgl,  msg2)); 

320  op_sim__end ("Error  in  badd_call_scheduler  process:", 
msgO,  msgl,  msg2); 


Dladnosttc  Block 


/*  Display  connection  information,  if  requested.  */ 
if  (LTRACE_CONNECT_ACTIVE) 

{ 

5  /*  Print  information.  */ 

ams_neighbor_data_print  (nbr_data_ptr,  ams_neighbor_desc_print_noop); 
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foreed  state  INIT 


attnbute 

vaiue 

type 

default  vaiue 

name 

INIT 

string 

St 

enter  execs 

(See  below.) 

textiist 

exit  execs 

(empty) 

textiist 

(empty) 

status 

forced 

toggle 

unforced 

/*  Determine  the  initial  values  of  the  state  variables  and  set  up 
/*  the  initial  state  of  this  instantiation  of  the  ams_traf_gen 
/*  process. 

5  /*  Obtain  the  object  ID  of  this  process*  parent  module. 

myjd  =  opjdself  0; 


10 


/*  Determine  whether  or  not  the  simulation  is  in  debug  mode. 
debug_mode  =  op__sim_debug  (); 

/*  Initialize  the  AAL  module  object  ID  to  NULL  value. 
aaI_module_id  =  OPG_OBJID_NULL; 
req_moduIe_id  =  OPC_OBnD_NULL; 


*/ 

*/ 

*/ 


*1 


*/ 


15 


/*  Create  a  list  for  storing  the  calls  as  they  arrive  */ 
calls_pending  =  op_prg_Iist_create(); 


20 


}*  Read  the  static  channels  input  file  and  create  lists  accordingly. 
static_channels  =  op_prgJist_create(); 
caljs_scheduled  =  op_prgJist_create(); 


*/ 


25 


30 


35 


40 


45 


/*  Open  the  channel  definition  file.  *1 

if  ((input^file  =  fopen(“ /usr/work/benton/input_channels ",  "r")) 

=  NULL) 

{ 

badd_call_sch_error(" Problem  opening  static  channel  definition  file.", 

OPC^NIL,  OPC.NIL); 

) 

if  (fgets  (  string,  MAXSIZE,  input  file )  !=  NULL) 

{ 

if  (LTRACE_CALL^CHANNELS_ACTIVE) 
printf("In  badd_call_sch.  init ;  string  is  %s  .  Nn",  string); 
if  (geCdigit(stiing,  &value)  =  OPC_COMPCODE_FAILURE) 

{ 

badd_cali_sch_error (“Invalid  number  of  static  channels.", 

OPC^NBL,  OPC^NIL); 

} 

total_channels  =  value; 
if  (LTRACE_CALL_CHANNELS_ACTIVE) 

{ 

printf("In  badd_call_sch.  load_static_channels  function  after  reading  channel"); 
printf(“  count ; total_channels  =  %d.  \n",  totaI_channels); 

} 

} 

if  (totaI_channels  >  MAX_CHANNELS) 

{ 

badd_calLsch_error(" Requested  virtual  channels  exceeds  maximum  allowed.", 
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OPC^NEL,  OPC^NEL); 

} 

50 

while  ((fgets  (  string,  MAXSIZE,  input^file  )  !=  NULL)  && 

(channeLcoimt  <  total  channels)) 

{ 

if  (LTRACE_CALL_CHANNELS_ACnVE) 

55  { 

printf("In  badd_call_sch. init ,  reading  each  channel  size,*"); 

printf(  “  ch anne  l_c  ount  =  % d .  \  n " ,  channel_count); 

printf("rn  badd_call_sch- init ;  string  value  is  %s .  \n“,  string); 

] 

60  if  (get_digit(string,  &value)  —  OPC_COMPCODE_FAILURE) 

{ 

badd_call_sch_error(" Invalid  number  for  static  channels.", 

OPC^NIL,  OPC^NIL); 

} 

65  if  (value  >8000000) 

{ 

badd_caIl_sch_error  ( 

} 

70  channeLptr  =  (Badd_QiaimeLDesc*)  op_prg^mem_alloc(sizeof(Badd_QianneLDesc)); 

if  (channeLptr  =  OPC_NIL) 

{ 

badd_calLsch_error( "Unable  to  allocate  memory  for  channel  definition.", 

OPC_NIL,  OPC^NIL); 

75  ] 

channeLptr->ch_capacity  =  value; 
channeLptr->ch_calls_sch  =  -1; 
channeLptr->ch_calls_compl  =  0; 
channeLptr->ch_compLtime  =  0.0; 

80 

op_prgJisLinsert(static_channels,  channeLptr,  OPC_LISTPOS_TAIL); 
if  (LTRACE^C  ALL^CHANNELS_ACmVE) 

{ 

printf("In‘ badd_call_sch.init,  channel  value  saved  =  %d.\n", channeLptr->ch_capacity); 
85  )  . 

/*  Create  a  list  to  store  the  calls  for  this  channel  */ 
channeLlistptr  =  op_prg_nst_create(); 
if  (channeLlistptr  =  OPC_NE.) 

90  { 

badd_calLsch_error( "Unable  to  allocate  memory  for  channel  list.", 

OPC.NIL,  OPC_NlL); 

} 

op_prgJistJnsert(caIls_scheduIed,  channeLlistptr,  OPC.LISTPOSJTAIL); 

95  chaimeLcount  =  channeLcount  +  1; 

} 

if  (LTRACE.CALL^CHANNELS^ACTIVE) 

{ 

channeLcount  =  op_prg_!isLsize(static_channeIs); 

100  printf("In  badd_call_sch . init ,  elements  in  static  channels  "); 
printf(  "list  =  %d.\n",  channeLcount); 
channeLcount  =  opjprgJist_size(calIs_scheduled); 
printf("In  badd_call_sch. init,  elements  in  sch_channels  "); 
printf( "list  -  %d.\n",  channeLcount); 

105  } 

fcIose(  input_file); 
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/*  Open  file  for  storing  call  timer  information.  *! 

110  if  ((output_file  =  fopen(" /us r /work/ben ton/ out put_cal l_times ",  "w")) 

=  NULL) 

{ 

badd_call_scb_error(" Problem  opening  output_call_times  file.", 
OPC_NIL,  OPC^NIL); 

115  } 


120 


125 


f*  Write  a  file  format  statement  as  the  first  line  in  the  file.  */ 

fputs("File  Format:  Channel  Enqueued_Time  Dequeued_Time  Time_In_Queue  PCR\n", 
output_file); 


/*  Open  file  for  storing  calls  completed  information.  *f 
if  ((output_calls  =  fopen(“ /usr/work/benton/output_cal  l_completed ",  "w 

=  NULL) 


{ 


badd_calLsch_error(" Problem  opening  output_call_complGted  file. 
OPC^NIL,  OPC^NIL); 


} 


)) 


130 


/*  Write  a  file  format  statement  as  the  first  line  in  the  file.  *! 

fputs("File  Format:  Channel  Time_completGd  PCR .  \n“,  output_calls); 


sch_channeLcount  =  op_prg_Iist_size(static_channels); 


135 


140 


145 


/*  Generate  PID  display  string.  *i 

sprintf  (pid_string,  "badd_call_scheduler  PID  (%d)  ",  op_pro_id  (op_pro_seIf  ())); 

/*  Obtain  and  send  out  neighbor  information.  *} 

nbr_data_ptr  =  aiiis_neighbor_data3uiId  (); 

ams_neighbor_notily  (nbr_data_ptr,  AMSC_MTYPE_AAL_CLIENT); 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 

{ 

printf("In  badd_call_scheduler.init :  print  neighbor  info.\n"); 
ams_neighbor_data_print  (nbr_data_ptr,  ams  neighbor_desc_print_noop); 

} 


!*  This  Scheduler _Module  is  attached  to  any  process  spawned  by  *1 
/*  this  badd_call_requestor process.  */ 

f*Scheduler_Module  =  (Badd_Sch_Mod_pata*)  op _prgjnem_alloc(sizeof(Badd_Sch_Mod_Data));  *f 
1 50  op_pro__modmem_instaII(&Scheduler_ModuIe); 

/*  Initialize  the  model  parameter  attributes.  */ 

op_ima_obj_attr^et  (my_id,  "scheduler  delay",  &time_to_next_scheduler); 
op  Jma_obj_attr_get  (my_id,  "transmission  delay ",  &trans_delay); 

155  op_ima_obj__attrjget  (my_id,  "channel  delay",  &channel_del ay); 
op_ima_obj_attr^et  (my_id,  "calls  pend  i  ng " ,  &max_calls_pending); 


/*  Initialize  the  end^simjime  varaible  */ 

op_ima_sim_attr_get(OPC_IMA_DOUBLE,  "duration",  &end_sim_time); 

if  (LTRACE.CALL^SCHEDULER.ACriVE) 

{ 


165 


printf("ln  badd_call_scheduler . init  state:  Leaving  init  state.  \n“); 


244 


Process  Model  Report:.badd_ca1Lschedulef_greedy 


Tue  Jun  17 10:52:08  1997  j  Page  18  of  38 
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f*  Amsjrafj^en  expects  either  a  neighbor  notification  interrupt, 
I*  or  a  spurious  signal. 
if  (NEIGHBOR^NOTDPY) 

{ 

5  /*  This  is  a  'neighbor  notify'  signal. 

if(LTRACE_ACTIVE) 


*/ 

*f 


*1 


10 


15 


op«prg_odb_print_major(pid_string,  -Received  neighbor  not  if  ication. OPC_NIL); 
} 

f*  Handle  the  neighbor  notification.  *1 

ams_neighbor_inteiTupt_handle  (nbr_data_ptr,  badd_caILsch_nbr_intrpt__proc,  OPC_NIL); 

} 

else 

{ 

/*  This  is  a  spurious  interrupt.  Handle  appropriately.  */ 

badd_calLsch_spurious_signal_handle  (); 

} 


^transition  confia  ->  confia  \ 

i^ribute 
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default  value 
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trj) 
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tr 

condition 
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color 

RGB333 
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spline 

toggle 

spline 
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transition  confia  ->  shared  data  | 
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unforced  state  disDalch  I 
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(See  below.) 
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(See  below.) 
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|g^CTg?g5M»TgT*^Vr4illMWM||||||||||||||||||i 

5 

!*  Compare  the  number  of  calls  in  the  calls jyending  list.  */ 

/*  If  the  number  exceeds  the  maxjcalls j>ending,  schedule  */ 

1*  a  call  to  execute  the  scheduler.  *f 

number_calls_pending  =  op_prgJist_size(calIs_pending); 

if  (LTRACE_CALJL_GREED  Y^ACTIVE) 

printf("ln  badd_call_scheduler. dispatch:  calls  pending  =  %d .  \n",  number_calls_pending); 

10 

if  (number_calls_pending  >  max„caJls_pending) 
opJntrpt_schedule__self  (op_sim_time  (),  BADD_CALL_SCHEDULER); 

15 

/*  Schedule  the  next  scheduling  event  */ 
if  (number_calis_pending  >  0) 

op  Jntrpt_schedule_self  (op_sim_time  ()  +  time_to_next_scheduIer,  BADD_CALL_SCHEDULER); 

temp_intrpt_type  =  op_intrpt_type(); 
temp_intipt_code  =  op_iDtrpt_code(); 

if  (LTRACE^C  ALL_DISP_ACTIVE) 

5  { 

printf(-ln  badd_call_scheduler .dispatch ;  received  SIGNAL. \n"); 
printf("In  badd_call_scheduler .dispatch :  intrpt_type  «  %d . \n“, temp_intrpt_type); 
printf(“In  badd„call_scheduler .dispatch :  intrpt_code  =  %d. \n", temp_intrpt_code)* 
}  /*  Endif(LTRACE_CALLJ)ISP_ACnVE)*{ 

10 

if  (SIGNAL) 

{ 

signa]_idptr  =  opjntrpt Jci(); 
if  (signaLiciptr  =  OPC_NIL) 

15  badd_call_sch_eiTOr( -Unable  to  get  signal_iciptr . OPC^NIL,  OPC^NEL); 

if  (LTRACE_CALL^DISP_ACTI  VE) 
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20 


( 

opJci_priDt(signaJJciptr); 

}  !*l:ndifiLTRACESALLJ)ISP_ACTIVE)*l 


op  ici_attr_get(slgna]_iciptr,  “primitive",  &primitive); 

} 
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attribute _ ::v:-  ■  - 


name 

condition 

executive 

color 

drawing  style 


value 
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:  forced  State  Start  call- ■  .  •  \ 

attribute 

value 

mmasmmam 

default  value 

name 

start  call 

string 

St 

enter  execs 

(See  below.) 

textiist 

exit  execs 

(empty) 

textiist 

(empty) 

status 

forced 

toggle 

unforced 

call  _ 

sch_channel_iciptr  =  op__intrpt_ici(); 

if  ((opJci_attrjget  (sch_chaimeljciptr,  “ channel  number" ,  &sch_channel_mdex)  =  OPC„COMPCODE_FAILURE)) 
badd_call_sch_eiTor("In  start_call:  unable  to  get  values  from  sch_channel  iciptr", 

OPC^NIL,  OPC_NIL); 


5 


/*  Destroy  the  id  to  recover  space.  Garbage  collection,  */ 
opJci_destroy(sch_chaimeIJciptr); 


if  (LTRACE^C  ALL^SCH.ACTIVE) 

10  printf("ln  call  scheduler  .start_call :  sch_channel  index  =  %d.  \n",  sch_chaimeLindex); 
sch_charmel Jistptr  =  (List*)  op jprgjist_access(calls_scheduled,  sch^channeLindex); 
calljciptr  =  (Id*)  op_prgJist__remove(sch_channeLlistptr,  OPC_LISTPOS_HEAD); 

if  (calljciptr  =  OPC_NIL) 

15  badd__caIl_sch_error("In  start  call,  unable  to  get  call_iciptr  from  cal ls_list . OPC_NIL,  OPC_NIL); 


if ((opJci_attr_get (calljdptr,  " interarriva  1  time",  &int_arr_tiine)  =  OPC_COMPCOl)E_FAlLTIRE)  11 
(op Jci_attr_get  (calljciptr,  "  packe t  size",  &packet_si2e)  =  OPC_COMPCODE_FAILURE)  II 
(op Jci_attrjget  (calljciptr,  "call  wait  time",  &calLwaitJime)  =  OPC_COMPCODE_FAILURE)  II 
20  (op Jci_attr jget (calLiciptr,  "call  duration", &caU_duration)  ==  OPC_COMPCODE_FAILURE)  II 

(op Jci^attrjget  (call Jciptr,  "dest  addr",  &dest_addr)  —  OPC_COMPCODE_FAILXXRE)  II 

(op Jci_attr^et  (calljciptr,  "  QoS  class",  &qos_class)  =  OPC_COMPCODE_FAILURE)  II 

(op Jci_attr_get  (calljciptr,  "AAL  type",&AAL_1ype)  =  OPC_COMPCODE_FAILURE)  11 

(op Jci_attr_get  (calljciptr,  "peak  cell  rate", &peak_celLrate)  =  OPC_COMPCODE_FAILURE)  II 
25  (op Jci__attrjget  (calljciptr,  “  t  ime  queued " ,  &time_enqueued)  =  OPC_COMPCODE_FAILURE)) 
badd_call_sch_enror( "Unable  to  get  values  from  call_req  iciptr",  OPC_NIL,  OPC_NIL); 


30 


35 


if  (LTRACE.C  ALL.SCHEDULER^ACTIVE) 

{ 


printf("In  badd_call_scheduler . start _ca  11 : 
printf("ln  badd_call_scheduler .  start _ca  11 : 
printf("ln  badd_call_scheduler. start _call : 
printf("ln  badd_call_scheduler . start _ca  11 : 
prmtf("In  badd_ca  ll_scheduler. start _ca  11 : 
printf("ln  badd_call_scheduler  .start_call : 
printf("In  badd_call_scheduler . start _ca  11 ; 
printf("In  badd_call_scheduler.start_call : 

}  /*  End  if{LTRACE_CALL_SCHEDULER_ACriVE)  */ 


int_arr_t  ime  =  %  f .  \n " ,  int_arr_time); 
packet_s  i  ze  =  %d .  \n " ,  packet^size); 
call_wait_t  ime  =  %f . \n",  call_wait_time); 
call_duration  =  %f  An",  call_duration); 
dest_addr  =  %d  An",  dest_addr); 
qos_class  =  ^d  An",  qos_class); 

AAL_type  =  %d  An",  AAL_type); 
peak_cell_rat€  =  %f  An",  peak_celLrate); 


40  if  (op  Jci_attr_set  (calljciptr,  "channel  a ss i  gned " ,  sch_chaimel_index)  ~  OPC_COMPCODE_FAILURE) 
badd_call_sch_error(  "Unable  to  set  sch_channel_index  in  cal  IJciptr",  OPC_NIL,  OPC_NIL); 

time_dequeued  =  op_simjime0; 
tiine_in_queue  =  tiine_dequeued  -  time_enqueued; 

45 

/*  Write  queue  times  to  the  call  timer  output  file.  *1 

tprintf(output_file,  "  %d  %f  %f  %f  %  f  \n " ,  sch_channel_index,  time_enqueued,  time_dequeued, 
time_in_queue,  peak_cell_rate); 
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/*  Update  program  counter  *1 
totaI_calls_generated  =  totaI_calls_generated  +  1; 
totaI_calls_active  =  total_calls_active  +  1; 
if  (total_calls_active  >  max_caUs_active) 
max_calls_active  =  total_calls_active; 

if  (LTRACE„CALL_SaffiDULER^ACriVE) 

{ 

priiitf("In  badd_call_scheduler,  start;  starting  call  to  dest  %d.\n", 
dest_addr); 

)  /*  if(LTRACE_CALLJCHEDULERJiCTIVE)  *1 
/*  Spawn  a  child  process  to  generate  the  call  data  *f 

calI_gen_prohandle  =  op_pro_create( "  c  1  ark^badd_ca  1  l_generator " ,  OPC_NIL); 
if  (op  jpro_valid(calI_gen_prohandle)  =  OPC^FALSE) 

{ 

badd_calLsch_error(" Unable  to  create  call  generator  process",  OPC_NIL,  OPC_NIL); 

} 

if  (LTRACE^C  ALL_SCHEDULER_.ACriVE) 

{ 

printf("In  badd_call_scheduler,  start;  invoicing  call  generator . \n"); 
printf("In  badd_call_scheduler. start :  call_iciptr  =  %x.  \n",  call_iciptr); 

printf( " In  badd_cal l_scheduler . start_cal  1 ;  md_aal_modul€_id  =  %d .  \n " ,  Scheduler_Module.md_aal_moduIe_id);| 
)  /♦  if(LTRACEj:ALLJCHEDULER_ACTrVE)  */ 
if  (LIltACE.CALL.TIMER^ACriVE) 

printf("In  badd_call_sch. start  call:  current  time  =  %£.\n",op  sim_time()); 

/*  When  invoking  the  process,  pass  in  the  call  desc  */ 

if  (op_proJnvoke(call^en_prohandie,  calljciptr)  =  OPC_COMPCODE_FAILURE) 

[ 

badd_calI_sch_error(" Unable  to  invoke  call  generator  process",  OPC_NIL,  OPC_NIL); 

} 
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Writer  execs  send  data  I 

signal  Jciptr  =  opjntrpt jci(); 

c 

if  (signaljciptr  =  OPC_NIL) 

badd_caILsch__error( "Unable  to  get  signal_iciptr. ",  OPC_NIL,  OPC_NIL); 

10 

if(LTRACE  CALL  SCHEDULER  ACTIVE) 

{ 

printf(“ln  badd_call_scheduler . send  data:  restarting  call_gen . \n"); 
op_ici_print(signal_iciptr); 

}  /*  Endif(LTRACE_CALL_SCHEDUlERJiCrTVE}*} 

15 

if  (op_ici_attrjget( signaljciptr,  "upper  layer  handle",  &upper_handle Jciptr)  =  OPC_COMPCODE_FAILURE) 
badd_calLsch_eiTor( "Unable  to  get  upper  layer  handle OPC_NIL,  OPC_NIL); 

if  (op  Jci_attrjget(upper_handle  Jciptr,  *  ca  1  l_gen_prohand  1  e " ,  &calI_gen_proplr)  —  OPC_COMPCODE_FAILURE) 
badd_call_sch_erTor( "Unable  to  get  call_gen  prohandle. ",  OPC_NIL,  OPC_NIL); 

20 

if(LTRACE_CALL^TIMER^ACTIVE) 

printf("ln  badd_call_sch.send  data:  current  time  =  %f . \n",  op_simJime()); 

if  (op_projnvoke(*call__gen_proptr,  signal^iciptr)  =  OPC_COMPCODE_FAILURE) 

f 

25 

badd_call_sch_error(" Unable  to  restart  call  gen  process ",OPC  NIL,  OPC  NIL); 

} 

transition  send  data  ->  dispatch  I 
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if  (signal_iciptr  ==  OPC_NIL) 

badd_call_sch_error( “Unable  to  get  signal_iciptr . OPC_NIL,  OPC_NIL); 
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5 

if  (LTRACE_CALL_SCHEDULER_ACTIVE) 

( 

printf("In  badd_call_sc'heduler.  cal  Incomplete:  restarting  call_gen.  \n"); 
opJci_priDt(signalJciptr); 

10 

)  /*  Endif(LTRACE_CALL_SCHEDULER_ACriVE)*l 

total_calIs_received  =  totalnCalls_received  +  1; 
totalnCalIs_active  ==  total_calIs_active  - 1; 

15 

if  (opJd_attr_get(signal_iciptr,  "upper  layer  handle",  &upper_handlejciptr)  —  OPCnCOMPCODE_FAILURE) 
b^dnCalLschnCrrorC "Unable  to  get  upper  layer  handle. ",  OPCnNIL,  OPC_NIL); 

if (op_ici_attr jget(signal_iciptr,  "traffic  contract",  &tmp_trafnConnptr)  =  OPCnCOMPCODEnFAILURE) 
bildnCalLsch_error(" Unable  to  get  traffic  contract OPC_NIL,  OPCnNIL); 

20 

if  (op_ici_attr ^et( signal  Jciptr,  " ba dd_ca  1 1  ngerinChanne  l_i  d " ,  &caIl_compLchannel)  =  OPC_COMPCODE_FAILURE) 
badd_caJLschnerror( "Unable  to  get  call_gen  prohandle. ",  OPCnNIL,  OPCnNIL); 

25 

/*  Write  completion  time  and  PCR  to  the  calls  completed  output  file.  */ 
tempnPCR  =  tmp_traf_con_ptr->calIing_ctd.srCntraf_desc.pcr; 

]4»rintf(ou^utnCalIs,  "%d  %f  %f\n",  calLcompLchannel,  op_sim_time(),  temp^PCR); 

30 

channeLptr  =  (BaddnChanneInDesc*)  op  prg  list  access(static_channels,  call_complnChannel); 
channeI_ptT->chnCalISnSch  =  channeLptr->ch_caUSnSch  -  .1; 
channelnptr->ch_callSnCompl  =  channeLptr->ch_calls_compl  +  1; 

if  (bp_ici__attr_^et(iipper_handle_iciptr,  " cal  lngen_prohandle ",  &calIngen_proptr)  =  OPCnCOMPCODEnFADLURE) 
baddnCall_sch_error( "Unable  to  get  call_gen  prohandle. ",  OPC_NIL,  OPCnNIL); 

35 

if  (LTI^CEnC  ALL.TIMERnACTIVE) 

printf(“In  badd_call_sch . call  complete:  current  time  =  %f.\n",op  sim  time()); 

if  (op  pro  invoke(*caIl_geD  proptr,  signal  iciptr)  =  OPC  COMPCODE  FAILURE) 

{ 

badd_caIlnSChnerror( "Unable  to  restart  call  gen  process",  OPC  NIL, OPC  NIL); 

} 

40 

1  transition  call  comolete  ->  dlsoatch  1 
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if  (signal  Jciptr  =  OPC_NIL) 

badd_calI_sch_error( -Unable  to  get  signal^iciptr .  OPC_NIL.  OPC_NIL); 

5 

if  (LTRACE_C  AIX.S<:HEDULm^ACTI\^^ 

{ 

printf(-In  badd_call_scheduler .call_released:  restarting  call_gen. \n"); 
opjci_print(signaI_iciptr); 

10 

}  1*  Endif{LTRACE_CALL_SCHEDULER_ACriVE}*l 

if  (opJci__attrjget($ignal_iciptr,  "upper  layer  handle".  &upper  handle  iciptr)  ==  OPC  CQMPCODP  FATT.TTRF.) 
badd_calLsch_error( -Unable  to  get  upper  layer  handle OPC_NIL,  OPC_NIL); 

15 

if (opJci_attrjget(signaJJciptr,  -badd_cal l_gen_channel_id &call_release_chaimel)  =  OPC_COMPCODE_FAILURE) 
badd_calLsch_error( -Unable  to  get  call_gen  call_release_channel .  OPC_NIL»  OPC_NIL); 

chaime!_ptr  =  (Badd_ChaimeLDesc*)  op_prgJist_access(static_channeIs,  call_release_channel); 
djannel_ptr->ch_calls_sch  =  channel_ptr->ch_cails_sch  - 1; 

20 

if  (opJci__attrjget(upper_handle Jciptr,  -call_gen_prohandle-,  &caII_gen^proptr)  =  OPC_COMPCODE_FAILURE) 
badd_calLsch_error( -Unable  to  get  call_gen  prohandle. ",  OPC^NIL,  OPC„NIL); 

total_calls_active  =  total_calls_active  - 1; 

25 

if(opj)ro  mvoke(*calI_gen_proptr,  signal  iciptr)  — OPC  COMPCODE  FAILURE) 

{  • 

badd__caILsch_eiTor(" Unable  to  restart  call  gen  process",  OPC  NIL,  OPC  NIL); 

} 

transition  caH  released  dispatch 


attribute _ value _ type _ default  value 


name 

trJ40 

String 

tr 

condition 

string 

executive 

string 

color 

RGB333 

color 

RGB333 

drawing  style 

spline 

toggle 

spline 

forced  State  shared  data  :  :  | 

attribute 

value 

default  value 

name 

shared  data 

string 

St 

enter  execs 

(See  below.) 

textiist 

exit  execs 

(empty) 

textiist 

(empty) 

status 

forced 

toggle 

unforced 

253 


Process  Model  Report:.  baddLcall  scheduler  gree^  .  .  t  Tue  dun  1710:^:08  1997  i  F^e  27  of  38  1 

e^er^xecs  data 


10 


/*  This  Scheduler _Module  is  attached  to  any  process  spawned  by  *l 
/*  this  baddjcall_scheduler  process.  */ 

op_pro_modinem_install(&Scheduler_Module); 

/*  Pass  the  neighbor  information  to  all  children  processes.  */ 
Scheduler_Module.md_neighbor_data_ptr  =  nbr_data_ptr; 
ScheduIer_ModuIe.md_aaLmodule_id  =  aaJ_moduleJd; 
Schediiler_Module.nid_to_aal_stream_index  =  to_aal_stream_index; 
ScheduIer_Module.md_cans_pending_ptr  =  calls_pending; 
ScheduIer_Module.md_chaiinel_delay  =  chaiuiel_delay; 


transition  shared  data  ->  dispatch  1 
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/*  This  is  a  spurious  interrupt.  Handle  appropriately.  */ 

prmtf("Bad  signal  received  by  badd_call_scheduler .  \n“); 
badd_calLsch_spurious_signaI_handle  (); 
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f*  Print  Information  during  testing  */ 

prmtf("Calls  currently  active  is  %d.\n",totaI_calls_active); 
prmtf("Max  calls  active  in  this  run  was  %d . \n\ max_calls_active); 

5  calls_list_si2e  =  opj[)rg_list_size(calIs_pending); 

prmtf("Calls  remaining  in  the  calls_pending  list  at  termination  =  % d . \n " ,  calls_list_size); 
printf("Cal Is  remaining  in  the  calls_scheduled  lists  at  termination.  \n"); 

10 

time_dequeued  =  end_siin_time; 

for  (channeLindex  =  0;  channeLindex  <  sch_channeLcount;  channeLindex-H-) 

{ 

15  channeLptr  =  (Badd_ChanneI_Desc*)  op_prgJist_access(static_channels,  channeLindex); 
calls_list_size  =  channeLptr->ch_calIs_sch; 
calLcompLchannel  =  channeLptr->ch_calls_compl; 
channeLcon^I_time  =  channeLptr->ch_compLtime; 

prmtf("  Channel  %d:  calls  compl  =  %d,  calls  remaining  =  %d,  completion  time  =  %f.\n“ 
dianneLindex,  calLcompLchannel,  calls_lisLsize,  channeLcompLtime); 
channeLlistptr  =  (List*)  op_prg_list_access(calls_scheduled,  channeLindex); 

for  (sch_channeLindex  =  0;  sch_channeLindex  <  calls_lisLsize;  sch_channel  index++) 

{ 

calLiciptr  =  (Id*)  op_prg_Iist_3ccess(channeLlis^tr,  sch_channeLindex); 
if  ((opJcLattr jget  (calljciptr,  "  t  ime  queued " ,  &time_enqueued)  =  OPC.COMPCODE^FAILURE)) 
badd_calLsch_error(*'In  End  Sim:  unable  to  get  values  from  call_req  iciptr", 

OPC.NEL,  OPC.NIL); 

30  time_in_queue  =  time_dequeued  -  tune__enqueued; 

/*  Write  queue  times  to  the  call  timer  output  file.  */ 

fprintf(outpuLfiIe,  "%d  %f  %f  %f\n", <±anneLindex, time_enqueued, 0.0, 0.0); 

/*  fprintfoutput Jile,  '*%d  channeljndex,  time_enqueued,  time_dequeued, 

35  !*  timejnjqueue);  */ 


if  (LTRACE_CALL_SCH_ACTIVE) 

{ 

40  badd_calLsch_lisLprint(chai}neLIistptr); 


/*  Close  the  Output  files.  */ 

45  fclose(outpuLfile); 
fclose(outpuLcalls); 

badd_calLsch_error( "Ending  simulation  in  badd_call_scheduler  .End  Sim.  \n",  OPC_NIL,  OPC_NIL); 


I  (gxgdy  End  Sim 


/*  A  call  request  arrived  from  the  call_requestor  above.  */ 

/*  Must  capture  the  call_request  information  from  the  *1 
!*  ICl  and  store  the  call  in  the  call _pendingjist  */ 

5  reqjciptr  =  opJntrptJd(); 
if  (req_iciptr  =  OPC_NIL) 

badd_call_sch_eiTor( “Unable  to  get  call_req  iciptr . OPC_NIL,  OPC_NIL); 

10  if  ((op_ici_attr_get  (req_iciptr,  "  interarrival  time ",  &int_arr_time)  ==  OPC_COMPCODE_FAILIJRE)  it 
(opJci_attr _get  (reqjciptr,  "packet  size",  &packet_size)  =  OPC_COMPCODE_FAILURE)  II 
(opJci_attrjget  (reqjciptr,  “call  wait  time",  &calLwaitJime)  ~  OPC_COMPCODE_FAILURE)  II 
(op JcL^ttr_get  (reqjciptr,  "call  duration",  &call_duration)  ==  OPC_COMPCODE_FAILlJRE)  II 
(opJci__attr_get  (reqjciptr,  -dest  addr ",  &dest_addr)  —  OPC_COMPCODE_FAILURE)  II 

15  (opjci^attrjget  (req^iciptr,  -QoS  class ",  &qos_class)  =  OPC_COMPCODE_FAILURE)  II 

(op Jci_attr jget  (req^iciptr,  - aal  type " ,  &AAL_type)  =  OPC_COMPCODE_FAILURE)  II 

(opjci_attr_get(req_iciptr, -peak  cell  rate",  &peak_celLrate)  =  OPC_COMPCODE_FAILURE)) 
badd_call_sch_error("ln  badd_call_sch.call_req:  unable  to  get  values  from  call_req  iciptr",  OPC__NIL,  0 

20  /*  Destroy  the  id  to  recover  space,  garbage  collection.  *1 
op  Jci_destroy  (req_iciptr) ; 

if  (LTRACE.C  ALL_SCHEDULER_ACTI  VE) 

{ 

25  prmtf("In  badd_call_scheduler.call_request :  int_arr_time  =  %f  An",  int^arrjime); 
printf("In  badd_call_scheduler  .call_request :  packet_size  =  %d  An",  packet_size); 
printf("In  badd_call_scheduler.call_request :  call_wait_t ime  =  %f  An",  call_waitjime); 
printf("In  badd_call_scheduler  .call_request :  call_duration  =  %f  An",call_dujration); 
printf("ln  badd_call_scheduler.call_request :  dest^addr  s  %d  An",  dest_addr); 

30  printf("In  badd_call_scheduler .call_request :  qos_class  =  %d  An", qos^class); 
printf(“ln  badd_call_scheduler.call_request :  AAL_type  =  %d  An",  AAL_t5qpe); 
printf("In  badd_call_scheduler  .call_request :  peak_cel l_rate  =  %f  An",  peak_cen_rate); 
printf("In  badd_call_scheduler  .call_request :  req_iciptr  %x  An",  reqjciptr); 

}  /*  EndifiLTRACE  CALLJCHEDUlERJiCTIVE)  *f 

35 

/*  Create  and  set  the  fields  in  the  interface  ICl.  ♦/ 

!*  -  Using  local  memory  -  */ 

ifjciptr  =  op_ici_create  (“badd_call_req_if_ici  "); 

40  op Jci_attr_set  (ifjciptr,  "interarrival  time",  mt_arr Jime); 
opJci_attr_set (if Jdptr,  "packet  size", packeOize); 
op Jci_attr_set (ifjciptr,  "call  wait  t ime " , calLwait Jime); 
op jci_attr_set  (ifjciptr,  “call  duration",  call_duration); 
op Jci_attr_set  (if Jciptr,  "dest  addr", dest_addr); 

45  op_ici_attr_set (if_iciptr,  "QoS  class", qos_class); 
opjci_attr_set  (if Jciptr,  "AAL  type",  AAL_type); 
op Jci_attr_set (ifjciptr,  "peak  cell  rate", peak_celljate); 
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op_prgJist_insert(calls_pending,  if Jciptr,  OPC_LISTPOS_TAIL); 
total_calIs_requested  =  total_calls_requested  +  1; 
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/*  Send  an  intrpt  to  start  the  scheduler  if  not  requested.  */ 
sch_requested  =  OPC_COMPCODE_JFAILURE; 

this_event  =  op_ev_current(); 
next^event  =  op_ev_nextJocal(this_event); 
while  (op_ev  valid(next_event)) 

{ 

if  ((op_ev_type(next_event)  ==  OPC_INTRPT__SELF)  && 

(op_ev  code(next_event)  =  BADD_CALL_SCHEDULER)) 

{ 

if  (LTRACE_CALL_SCH^ACTIVE) 
printf("Found  scheduler  event,  stopping  search.  \n"); 
sch__requested  =  OPC_COMPCODE_SUCCESS; 
break; 

} 

else 

{ 

next_event  =  op_ev_Dext Jocal(next_event); 

} 

} 


75 


!*if{schjrequested  ==  OPC_COMPCODE_FAILURE) 
f*( 

/*  if(LTRACEj:ALLJCH_ACTIVE) 

}*  printfC* Sending  for  scheduler  interrupt Xn’*); 

!*  op_intrpt_schedule_self  ( opjsimjime  ( ),  BADD  _CALL_SCHEDULER}; 
I*}  *f 
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f*  Disable  the  intrpts  to  make  this  process  atomic.  */ 

op^intrpt^disable(OPC_INTRPT„SELF,  BADD_CALL_SCHEDULER,  OPC^FALSE); 
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/*  Remove  all  the  other  events  of  this  type  from  the  events  list. 
this_event  =  op__ev_current(); 
next_event  =  op_ev_next JocaI(this_event); 
while  (op_ev_vaIid(next_event)) 

{ 

if  ((op_ev_type(next_event)  =  OPCJNTRPT^SELF)  && 

(op_ev_code(next.event)  =  BADD_CALL_SCHEDULER)) 

f 

if  (LTRACE.C  ALL„SCH_ACnVE) 

printf(" Found  next  sch  event,  deleting  event. \n"); 
scheduler_event  =  next_event; 
next_event  =  op_ev_nextjocal(scheduler_event); 
op  ev_caDcel(scheduler  event); 

) 

else 

next_event  =  op_ev_next Jocal(next_event); 

} 

/*  Determine  the  number  of  calls  that  must  be  scheduled.  *! 
calls_list_si2e  =  op_prgJist_size(calls_pending); 

if  (LTRACE.C  ALL^GRBED  Y.ACTIVE) 

{ 

if  (calls_list__size  =  0) 

printf("In  t)add_call_scheduler .call  scheduler,  attempted  to  schedule  empty  list."); 
else 

printf("In  badd_call_scheduler .call  scheduler,  calls  list  size  =  %d.  \n",  calls_list_size); 

} 

/*  Initializevariables  for  find  first  call  and  channel  to  schedule.  */ 

Ieast_compLtime  =  MAX_COMPL_TIME; 
least_channeLindex  =  -1; 
least_call_index  =  -1; 

/*  Create  and  Initialize  the  scheduling  matrix.  */ 

temp_calls_sch_list  =  op_prgJist_create(); 

for  (row^index  =  0;  row_index  <  calls_Iist_si2e;  row_index++)  * 

{ 

/*  Access  a  call  description  in  the  calls  j>ending  list.  *! 
call_iciptr  =  (Id*)  op_prgJist_access(calIs_pending,  row_index); 

if  (calljdptr  =  OPC.NIL) 

b^d_caII_sch_error("In  badd_call_scheduler.call  schedule,  unable  to  get  call_iciptr . 
OPC^NDL,  OPC.NIL); 

/*  Get  the  call-duration,  calfwait_time,  and  peak  cell _rate  from  the  call  descriptor.  */ 
if  ((op Jci_attr jget  (calljdptr,  "call  duration",  &calLdiiration)  =  OPC_COMPCODE_FAILURE)  II 
(op Jci_attr jget  (call Jciptr,  "call  wait  time",  &call_wait_time)  =  OPC_COMPCODE_FAILURE)  II 
(op Jci_attrjget (calljciptr,  “peak  cell  rate", &peak_ceILrate)  =  OPC_COMPCODE_FAILURE)) 
badd_call_sch_error(" In  badd_sch .call  schedule:  unable  to  get  values  from  call_req  iciptr.", 
OPC.NIL,  OPC_NIL); 

if  (LTRACE,CALL„GREEDY_ACTIVE) 

{ 

printf("In  badd_call_scheduler .cal  1  schedule:  peak_cel l_rate  =  %f.\n", 
peak_ceILrate); 

}  /♦  End  if(LTRACE_CALLJCHEDULER_ACTIVE)  */ 
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calLbit_rate  =  peak_celLrate  *  AMSC_ATM_CELL_SIZE; 

/*  Create  channels  list  for  this  call.  */ 

65  sch_channeLIistptr  =  op_prgJist_create(); 
if  (sch.chaimeLlistptr  =  OPC_NIL) 

badd_caU_sch_en'or( “ In  badd_call_scheduler.call  schedule,  unable  to  create  sch_channel_listptr . 
OPC_NIL,  OPC^NIL); 

70  /*  Insert  the  channels  list  into  the  scheduling  matrix  as  a  row.  */ 

op j)rgjistjnsert(temp_calls_schjist,  sch^channeljistptr,  OPCJLISTPOS_TAIL); 

/*  Calculate  the  completion  time  for  this  call  on  every  channel  and  store  in  the  scheduling  */ 

/*  matrix.  *1 

75  for  (coLindex  =  0;  coLindex  <  sch_chaiineLcount;  coLindex++) 

{ 

/*  Allocate  space  to  store  channel  completion  time.  *! 
compLtime^ptr  =  (double*)  op_prg_mein_aIIoc(sizeof(double)); 

80  if  (L']11ACE_CALL_GREEDY^ACTIVE) 

{ 

printf("In  badd_call_scheduler.call  scheduler:  row_index  =  %d,  col_index  =  %d.\n", 
row_index,  coLiodex); 

} 

85 

/*  Get  the  channel  descriptor.  */ 

chaimeLptr  =  (Badd_ChanneI_Desc*)  op_prg_list_access(static_channels,  col_index); 
if  (LTRACE^C  ALL_GREEDY_ACriVE) 

{ 

90  prmtf("In  badd_call_scheduler.call  scheduler,  ch_capacity  =  %d.  \n“,  channel_ptr->ch_capacity); 

printf("In  badd_call_scheduler.call  scheduler,  bit  rate  =  %d.  \n",  call_bit_rate); 

) 

/*  Determine  if  this  channel  can  support  the  call  */ 

95  if  (call_bit_rate  <=  channeLptr->ch_capacity) 

{ 

if  (op_sim_time  ()  >  channeLptr->ch_compl_time) 

{ 

*compLtiine_ptr  =  op_siin_tlme()  +  call_duration  +  channel_delay  +  trans_delay; 

100  /*  *compl_time _ptr  =  op_sim_time()  +  call  duration;  */ 

} 

else 

{ 

*compI_tiine_ptr  =  channeLptr“>ch_compl_time  +  call_duralion  +  channeLdelay  +  trans_delay; 

105  /*  *compljime _ptr  =  channel _ptr~>ch_compljime  +  call jdurat ion;  */ 

] 

/*  Determine  if  this  channel  has  a  shorter  completion  time  than  all  previous  channels.  *1 
if  (*compLtime_ptr  <  least_compLtime) 

110  { 

least_channel_index  =  coLindex; 
leasLcalLindex  =  row_mdex; 
leasLcompLtbne  =  *compLtune_ptr; 

} 

115  } 

else 

{ 

*compLtime_ptr  =  MAX_COMPL_TIME; 

} 

120 
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if(LTRACE_CALL„GREEDY  ACTIVE) 

{ 

printf("In  badd_call_scheduler .call  schedule;  compl  time  = 

*compl_time__ptr); 

}  /*  Endif(LTRACEjCALL_GREEDYj\CT!VE)  */ 

125 

/*  Store  the  completion  time  in  the  matrix.  */ 

op_prg_listJnsert(sch_channeLIistptr,  compl_time_ptr,  OPC_LISTPOS_TAIL); 

130 

}  /*  End  for  [col Jndex  =  0;  coljndex  <  sch_channel_count;  colJndex++}  *f 
}  I*  for  (row Jndex  ~  0;  row  Jndex  <  calls Jistjsize;  rowjndex^-^-}  *l 

135 

/*  Initialize  the  number  of  calls  to  schedule.  *J 
remain_to_scheduie  =  calls_iist_size; 

while  (remam__to_schedule  >  0) 

/ 

140 

1 

/*  During  initialization  of  scheduling  matrix,  found  the  first  call  and  channel  to  schedule.  *! 

/*  On  all  subsequent s  calls,  call  and  channel  to  schedule  are  completed  at  the  end  of  the  */ 

/*  while  loop.  *! 

if  (LTRACE_CALL_GREEDY_ACTIVE) 

f 

145 

i 

printf("ln  badd_call_scheduler .call  schedule:  least_channel  %d,  least_call  %d,  least_compl  %f.\n" 
least_channel_index,  least_call_index,  least_compI_time); 
badd_call_sch_matrix_print(temp  calls  sch  list); 

) 

150 

if  (least_calLindex  <  0) 

badd_call_sch_eiTor(" Unable  to  schedule  any  calls,  call  exceeds  channel  capacities.", 

OPC_NIL,  OPC.NIL); 

/*  Remove  the  call  from  the  calls jpending  list.  */ 

call_iciptr  =  (Id*)  op_prg_Iist__remove(cails_pending,  least_call_mdex); 

155 

/*  Time -stamp  the  request  with  the  current  time.  *1 
op_ici_attr_set  (call_idptr,  "time  queued  “ ,  op_sim_time()) ; 

160 

/*  Put  the  call  at  the  tail  of  the  correct  channel  calls  scheduled  list.  */ 
channeLIistptr  =  (List*)  op_prgJist_access(calls_scheduled,  Ieast_channeLindex); 
op_prg_IistJnsert(channeI_listptr,  calljciptr,  OPC_LISTPOS_TAIL); 

165 

/*  Remove  the  row  from  the  matrix  and  return  the  memory  to  system.  This  kernal  */ 

/*  process  also  deallocates  all  memory  for  the  list  elements.  */ 

row_listptr  =  (List*)  op_prg_Iist__remove(temp_calls_sch_list,  least_call_index); 
op_prg_list_free(rowJistptr); 

170 

!*  Update  the  calls  scheduled  counter  *1 

channeLptr  =  (Badd_ChaimeLDesc*)  op_prg_list__access(static_channels,  least_channeLmdex); 
channel_ptr->ch_calls_sch  =  chaiineLptr“>ch_calls_sch  +  1; 

f*  If  this  is  the  first  call  on  the  channel,  start  the  channel.  */ 
if  (channeLptr->ch_calls_sch  =  0) 

/ 

175 

\ 

if  (LTRACE_CALL_GREEDY_ACnVE) 
f 

printf("in  badd„call_scheduler.call  scheduler,  calling  start  call  for  channel  %d.\n", 

1  east_channel_index) ; 

} 
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/*  Identify  the  channel  to  start  sending  data.  *! 
channeljcriptr  =  opJci_create(  "badd_channel_ici "); 
opjcijnstall(channeljciptr); 

op_ici_attr_set (channel_iciptr,  "channel  number",  Ieast_channel_mdex); 
op Jntrpt  $cbedule__self  (op  sim  time  (),  B ADD  CALL_SCH  START); 

}  *"  ^  • 


/*  Update  the  channel  completion  timer.  */ 

^ ((opjci_attrjget  (call_iciptr,  "call  duration",  &call_duration)  =  OPC_COMPCODE_FAn^URE)  II 
(op_ici_attr^et (call_iciptr,  "call  wait  time", &call_wait_time)  =  QPC  COMPCODR  FATT J IRE)) 
badd_caILsch__eiTor( " In  badd^sch.call  schedule:  unable  to  get  values  from  call_iciptr . 
OPC^NIL,  OPC.NIL); 

if  (op_sim_time  ()  >  chaimeI_ptr->ch_compLtime) 

{ 

channel_ptr->ch_compLtune  =  op_sim_time()  +  calI_diiration  +  channeLdelay  +  trans_delay; 

/*  channel j>tr~>ch_compljime-op  simjime()  +  call_duration;  V 

} 

else 

{ 

channeLptr->ch_compLtinie  =  channeI_ptr->ch_compl_tiine  +  calLduration  -i-\ 

+  channel_de!ay  +  trans_delay; 

/*  channel _ptr->chj:ompl_time  =  channel _ptr->chj:ompljime  +  calljluration;  */ 

} 

if  (LTRACE__CALL_GREEDY_ACTIVE) 

{ 

•printf(“In  badd_call_scheduler.call_schedule;  compl_time  =  %f  .\n",  channeLptr->ch_compLtime); 
printf("In  badd_call_scheduler.call  scheduler:  call  scheduled. \n"); 

} 

channeLscheduled=  OPC^COMPCODE^SUCCESS; 

remain_to_schedule  =  remain_to_schedule  - 1; 

coLindex  =  Ieast_channeLindex; 

least_channeLindex  =  -1; 
least_calLindex  = -1; 

!east_compLtime  =  MAX_COMPL_TIME; 

/’*'  Get  the  channel  completion  time  and  update  the  channel  column  in  the  scheduling  matrix.  *! 
channel_ptr  =  (Badd_ChanneLDesc*)  op_prgJist__access(static_channeIs,  coI_index); 

/*  Step  through  each  job  in  the  calls  j>ending  list  and  update  the  channel  column  in  the  *f 
f*  scheduling  matrix  with  a  new  channel  completion  time.  *1 

for  (row_mdex  =  0;  row_index  <  remain_to_schedule;  row_index++) 

{ 


if  (LTRACE_C  ALL^GREEDY_ACTIVE) 

{ 

piintf("In  cal l_scheduler .call_schedule :  updating  row  %d,  col  %d.\n", 
row_mdex,  col_index); 

} 

/*  Get  the  location  for  the  current  matrix  element.  *} 

sch_chaimeLUstptr  =  (List*)  op_pfgJist_access  (temp_calls_sch_list,  row_index); 
compLtime_ptr=  (double*)  op_prgJist_access  (sch_chaimel_Iistptr,  coI_index); 

/*  Only  update  the  completion  time  if  the  call  can  run  on  this  channel.  */ 
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if  (*compl_time_ptr  <  MAX_COMPL_TIME) 

{ 

I*  Get  the  calljiuration  time  from  the  call  descriptor.  *l 
calljciptr  =  (Id*)  op_prgJist_access(calls_pending,  row^index); 

((op_ici_attrjget(call_idptr,  "call  duration", &calJ_duration)  =  OPC_COMPCODE_FAILURE)) 
badd_call_sch_erTor("In  cal l_scheduler. schedule:  unable  to  get  call_duration. ", 
OPC.NIL,  OPC^NIL); 

if  (op_sim_time  ()  >  channeLptr->ch_compl_tiine) 

( 

*compl_time_ptr  =  op__sim_time()  +  calJ_duration  +  channel_delay  +  trans_delay; 

*compljime _ptr  -  op _sim_time(}  +  calljiuration;  */ 

} 

else 

{ 

*compLtime_ptr  =  chaimeI_ptr->ch_compLtime  +  call_duralion  +  channel_delay  + 
trans_delay; 

*compljime _ptr  =  channel _ptr->ch  compljime  +  calljiuration;  */ 

) 
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)  /*  End  if(*compljime  j)tr  <  MAXJOOMPLJTIME)  */ 

}  /*  End  for  (rowjndex  =  0;  rowjndex  <  remainjojchedule;  rowJndex+-{‘ )  */ 

f*  After  updating  the  completion  time  for  each  call,  step  through  the  entire  scheduling  */ 
/*  matrix  looking  for  the  next  call  to  schedule.  *} 

for  (row_index  =  0;  row_index  <  remain_to_schedule;  row_index-H-) 

{ 

for  (coLindex  =  0;  col_index  <  sch_channeLcount;  coLindex++) 

{ 

/*  Get  the  current  location  in  the  scheduling  matrix.  */ 

sdi_chaimel_listptr  =  (List*)  opjprg_list__access  (temp_calls_sch_iist,  row_index); 
compI_time__ptr  =  (double*)  op jprgjist_access  (sch_channel_Iistptr,  coLindex); 

/*  Determine  if  this  channel  has  the  shortest  completion  time.  */ 
if  (*compl_time_ptr  <  least_compLtime) 

{ 

least_channel_index  =  coLindex; 
ieasLcalLindex  =  row_index; 
leasLcompLtime  =  *compLtime_ptr; 

}  /*  End  if  (* compljime j>tr  <  least jompljime)  */ 

}  /*  End  for  ( coljndex  =  0;  coljndex  <  schjhannel  count;  coljndex++)  */ 

}  /*  End  for  ( rowjndex  =  0;  rowjndex  <  remain jojschedule;  rowJndex++)  */ 

}  /*  End  while  (remain jojchedule  >  0)  */ 

/*  remove  the  list  to  deallocate  memory  resources;  garbage  collection.  */ 
op_prgJisLfree(teii^_calis_sch_list); 

/*  Turn  the  interrupts  back  on.  */ 

op_intrpt_enabIe(OPC_INTRPT_SELF,  BADD_CALL_SCHEDULER); 
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req_iciptr  =  op  JntrptJci(); 
if  (req_ic!ptr  =  OPC_NIL) 

badd_caIl_sch_error( “Unable  to  get  call_req  iciptr. ",  OPC_NIL,  OPC  NIL); 

5 

if  ((opJci_attrjget  (rec|_iciptr,  “interarrival  time ",  &int_anLtime)  =  OPC_COMPCODE_FAILURE)  II 
(op Jci_attr jget  (req Jciptr,  "  pa  cket  size",  &packet_size)  =  OPC_COMPCODE_FAILURE)  II 
(op JcL^ttrjget (req Jciptr,  "call  wait  time", &calLwait_time) ~ OPC_COMPCODE_FAILURE)  II 
(op Jci^attrjget  (req_iciptr,  "call  duration",  &caIl_duration)  =  OPC__COMPCODE_FAILIJRE)  ll 
to  (op Jci_attr Jget  (req Jciptr,  “de St  addr",  &dest_addr)  =  OPC_COMPCODEJFAILURE)  II 

(op Jci_attr__get  (reqjciptr,  "QoS  class",  &qos_class)  ==  OPC_COMPCODE_FAILURE)  ll 

(opJci_attrjget  (req_iciptr,  -AAL  type ",  &AAL_type)  =  OPC_COMPCODE_FAILURE)  II 

(op Jci  attr Jget  (reqjciptr,  "peak  cell  rate",  &pealc_cell_rate)  =  OPC_COMPCODE_FAILURE)  II 
(op Jci_attr jget  (reqjciptr,  "  channe  1  ass  i  gned " ,  &calLrelease_channeI)  =  OPC_COMPCODE_FAILtJRE)) 

15  badd_call_sch_error("In  badd_call_sch.  reschedule:  unable  to  get  values  from  call_req  iciptr",  OPC_NIL, 

opjci_destroy(reqjciptr); 

if  (LTRACE^C  ALL.RESCHEDULER_ACTIVE) 

20  { 

printf("In  badd_call_scheduler  .reschedule:  int_arr_timG  =  %f .  \n",  int_aiTjime); 
printf("ln  badd_call_scheduler .reschedule:  packet_size  =  %d . \n", packet^size); 
printf("ln  badd_call_scheduler .reschedule:  call__wait_t ime  =  . \n", call_wait_tiine); 

pTintf("In  badd_call_schGduler. reschedule:  call_duration  =  %f . \n“, calI_duration); 

25  printf("ln  badd_call_scheduler  .reschedule:  dest_addr  =  %d .  \n",  dest_addr); 
printf("In  badd_call_scheduler .reschedule:  qos_class  =  %d . \n",  qos_class); 
printf("In  badd_call_scheduler .reschedule:  AAL_type  =  %d. \n", AAL_type); 
printf("In  badd_call_schedulGr. reschedule;  pGak_cell_rate  =  %f . \n“, peak_cell_rate); 
printf("In  badd_call_scheduler. reschedule:  req_iciptr  =:  %x.  \n ",  reqjciptr); 

30 

prin1f("In  badd_call_scheduler .reschedule;  current  sim  time  =  %f .  \n",  op__sim  time()); 

)  f*  End  if(LTRACE_CALL_RESCHEDUlER_ACriVE}  *f 

/*•  Reduce  the  channel  completion  time  for  this  call,  it  is  added  back  in  when  the  call  */ 

35  /*  is  rescheduled.  */ 

channeLptr  =  (Badd_ChanneLDesc*)  op_prgJist_access(static_channeIs,  calLrelease_channel); 
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channeLptr>>ch_compl_time  =  channel_ptr->ch_compI_tixne  -  calLduration  -  channeLdelay  -  trans_delay; 


40 


i*  Create  and  set  the  fields  in  the  interface  JCI. 
ifjciptr  =  opJci_create  (-badd_cal  l_req_i  f_ici  "); 


*/ 


op_ici__attr_set  (if_iciptr,  "  i nt e rarr  i va  i  time",  int_arr_time); 
op Jci_attr_set  (if_iciptr,  "packet  size",  packet^size); 

0 p_ici_attr_set (if_iciptr,  "call  wait  time", call_wait_time) ; 

45  op  Jci_attr_set  (if_iciptr,  "call  dur at  ion",  caII_duration); 
opJci_attr__set  (ifjciptr,  "dest  addr",  dest^addr); 
op Jci_attr_set  (ifjciptr,  "QoS  class",  qos_class); 
op Jci_attr_set (if Jciptr,  "AAL  type",  AAL„type); 
op Jci_attr_set (if Jciptr,  "peak  cell  rate", peak_cell_rate); 

50 

op_prgJistJnsert(calls_pending,  iLiciptr,  OPC_USTPOS_HEAD); 


55 


/*  ifischjequested  ==  0 PC  COMPCODE  FAILURE) 

I*  opJntrpt_schedule_self  { op^simjime  ( },  BADDjCALL  SCHEDULER );  *1 
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\  enter  execs  check  Channel  1 

/*  Get  the  Id  passed  from  the  calljgenerator  and  determine  what  channel  must  */ 

/*  be  checked  for  additional  calls.  If  the  channel  has  additional  calls  waiting,  */ 

/*  then  send  an  interrupt  to  start  the  next  call.  */ 

5 

check_channeLiciptr  =  opJntrptJci(); 

if  (op  Jci_attrjget  (check_channel  Jciptr,  "  channe  1  number " ,  &check_chan_index)  =  OPC_COMPCODE_FAILURE) 
badd_call_sch„eiTor(" Unable  to  read  check  channel  icipt r. ",  OPC_NIL,  OPC_NIL); 

10 

op_ici_destroy(check_chaiineIJciptr); 

if  (LTRACE.C  ALL^SCH.ACTI  VE) 

printf("In  badd_call_scheduler  .call  scheduler  .check_channel :  channel  =  %d .  \n",  checfc_chan_index); 
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25 


channeLptr  =  (Badd^ChanneLDesc*)  op_prgJist_access(static_channeIs,  check_chan_index); 

/*  Check  the  channel  for  additional  calls  waiting  and  start  the  next  call  if  available.  */ 
if  (channel_ptr->ch_calls__sch  >=  0) 

{ 

channeljciptr  =  opJci_create(  "badd_channel_ici "); 
op_icMDStall(channeI_iciptr); 

op jci_attr_set (channeljciptr,  "channel  number",  check_chan_index); 

op  intrpt  schedu!e_self  (op  sim  time  ()  +  channel  delay,  BADD_CALL  SCH_START); 

} 

if  (LTRACE_C  ALL.TIMER^ACTIVE) 

printf("In  badd_call_sch.  check  channel;  current  time  =  %f  .\n",  op_simJime()); 


transition  check  channel  ->  dispatch 
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